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Abstract 


We define what it means for a network of communicating players to securely compute a 
function of privately held inputs. Intuitively, we wish to correctly compute its value in a manner 
which protects the privacy of each player’s contribution, even though a powerful adversary may 
endeavor to disrupt this enterprise. 

This highly general and desirable goal has been around a long time, inspiring a large body 
protocols, definitions, and ideas, starting with Yao (1982, 1986] and Goldreich, Micali and 
Wigderson [1987]. But all the while, it had resisted a full and satisfactory formulation. 

Our definition is built on several new ideas. Among them: 


e Blending privacy and correctness in a deeper manner, using a special type of stmulator 
designed for the purpose. 

e Requiring adversarial awareness—capturing the idea that the adversary should know, in 
a very strong sense, certain information associated to the execution of a protocol. 

e Imitating an ideal evaluation in a run-by-run manner, our definition depending more on 
individual executions than on global properties of ensembles. 


Among the noteworthy and desirable properties of our definition is the reductbility of secure 
protocols, which we believe to be a cornerstone in a matu- * theory of secure computation. 


An earlier draft of this paper was presented and distributed at a DIMACS workshop 
on cryptography, October 1990. The paper continues to evolve; this is a preliminary 
report on our work. 
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1 Introduction 


The last decade has witnessed the rise of secure computation as a new and exciting mathematical 
subject. This is the study of communication protocols allowing several parties to perform a correct 
computation on some inputs that are and should be kept private. As a simple example, the parties 
want to compute the tally of some privately held votes. This new discipline is extremely subtle, 
involving in novel ways fundamental concepts such as probabilism, information, and complexity 
theory. 

In the making of a new science, finding the correct definitions can be one of the most difficult 
tasks: from relatively few examples, one should handle cases that have not yet arisen and reach 
the highest possible level of generality. It is the purpose of this paper to identify the right notion 
of secure computation and prove the right fundamental properties about it. 

In the last few years, cryptography has been very successful in identifying its basic objectives, 
properly defining them, and successfully solving them. Secure encryption, secure pseudorandom 
generation, secure digital signatures, and zero-knowledge proofs—concepts that appeared forever 
elusive—have all found successful formalizations and solutions. But in contrast to these successes, 
and despite many beautiful and fundamental ideas that preceded us, not even a satisfactory def- 
inition of a secure protocol has been proposed so far. This is not surprising, since protocols are 
an extremely complex object: by defining security for encryption, signatures, and pseudorandom 
generation, one is defining properties of algorithms; but to properly define protocol security, one 
needs instead to define properties of the interaction of several algorithms, some of which may be 
deliberately designed to disrupt the joint computation in various ways. The intricacy of this sce- 
nario has often encouraged researchers to work either with definitions of security tailored to the 
problem at hand; or to consider broad definitions, but restricted to specific computational tasks; 
or to work with only intuitive notions in mind. 

Lack of universally accepted definitions can only create confusion iid mistakes, and it is only 
by reaching an ezact understanding of what we can expect from a secure protocol can we safely 
rely on them and further develop them. By developing the right notion of secure computation we 
will spare cryptography the increasing dangers of confusion, error, and misunderstanding. Powerful 
computer networks are already in place and the possibility of using them for new and wonderful 
tasks will largely depend on how successful this development will be. The goal is definitely worth 
the effort, for its potential applications and from a purely intellectual point of view. Lets us begin! 


1.1 Secure-Computation Problems 


What is secure computation about? Informally, it consists of finding a communication protocol 
that allows a group of players to accomplish a special type of task, despite the fact that some of 
them may try to sabotage this enterprise. This said, we now explain terms. Let’s start with the 
easy ones. 

Players (also called processors or parties for variation of discourse) can be thought as people, 
each possessing a personal computer, and capable of exchanging messages. A protocol is a set 
of instructions for the players to follow for sending these messages. The rules of the game are as 
follows: (1) in executing a protocol, some of the participants may be bad, thereby disregarding their 
instructions and cooperating to disrupt the joint effort; (2) no trusted device or external entity is 
available; (3) every good party can perform private computation (i.e., computation unmonitored 
by the bad players). 

What is a secure protocol supposed to accomplish? We start by looking at a few archetypal 
examples. Since our aim is to exemplify various issues and key desiderata that may inspire us 


to properly define secure computation, in the following list we credit the one who first posed the 
problem. 


1. THE MILLIONAIRES PROBLEM (Yao, [Ya82a]). Two millionaires wish to find out who is 
ticher, though neither is willing to reveal the extent of his fortune. Can they carry out a 
conversation which identifies the richer millionaire, but doesn’t divulge additional information 
about either’s wealth? 


2. THE DIGITAL VOTING PROBLEM (Chaum, [Ch81]). Is it possible for a group of computer 
users to hold a secret-ballot election on a computer network? 


3. THE INDEPENDENT ANNOUNCEMENT PROBLEM (Chor, Goldwasser, Micali, and Awerbuch 
[CGMA85]). A group of players want to exchange messages so as to announce their secret 
values independently. That is, what the bad players announce cannot be chosen based on the 
values of the good players. 


4. THE COIN FLIPPING PROBLEM (Blum, [B182]). How can Alice and Bob, speaking to one 
another over the telephone, agree on a random, unbiased coin flip—even if one of them cheats 
to try to produce a coin flip of a certain outcome? 


5. THE OBLIVIOUS TRANSFER PROBLEM (Rabin, [Ra81]). Is it possible for Alice to send to Bob 
a message m in such a way that (i) half the time, Bob gets m; (ii) the other half of the time, 
Bob gets nothing; and (iii) Alice never knows which of the two events has occurred? 


6. THE MENTAL POKER PROBLEM (Shamir, Rivest and Adleman, [SRA81]). Can a group of 
players properly shuffle and deal a deck of cards over the phone? 


1.2 Privacy and Correctness 


Even the above short list illustrates the enormous variety of types of goals for secure protocols. 
There may be two parties or many. The output of a protocol may be a single value known to all 
players (as in digital voting), or to only one of the players (as in an oblivious transfer), or it may 
be a private value for each player (as in mental poker). The output may depend on the players’ 
initial state deterministically (as in the first three problems), or probabilistically (as in the last 
three problems). 

What do such heterogeneous problems have in common, then? Essentially, that the joint com- 
putation should both be private and correct: while preserving the privacy of individually held data, 
the joint computation manages to correctly perform some computational task based on this data. 
Correctness and privacy may seem to be conflicting requirements, and capturing in the most general 
sense what simultaneously meeting them means (within our rules of the game) is quite difficult. 
As we shall see, to obtain a satisfactory notion of security, privacy and correctness should not be 
handled independently (like in all prior work), but need to be blended in the proper way. 


1.3 Prior and Related Definitions 


Y-EVALUATION. Distilling a common thread in many prior examples of secure computation, Yao 
proposed the following general problem [Ya82a]. Assume we have n parties, 1,...,m. Each party z 
has a private input, z;, known only to him. The parties want to compute a given function f on 
their own inputs while maintaining the privacy of these inputs. In other words, they want to 
compute y = f(z,,...,2,) without revealing to any player more about the private inputs than the 


output itself implicitly reveals. If the function is vector-valued, 7 = f(z1,-.-,2n), where § has n 
components, it is desired that every party 7 privately learn the i-th component of /. 

Yao also proposed a notion for what it means for a protocol to solve the above problem. Roughly 
said, his formalization attempts to capture the idea that the worst the bad players can do to 
disrupt a computation is to choose alternative inputs for themselves, or quit in the middle of the 
computation. We will refer to this notion of security as Y-evaluation. Subsequently [Ya86], Yao 
strengthened his notion of a Y-evaluation so as to incorporate some fairness constraint. A fair 
protocol is one in which there is very little advantage to be gained by quitting in the middle. That 
is, the protocol takes care that, at each point during the execution, the “informational gap” among 
the players is small. The study of fair protocols was started earlier by Luby, Micali, and Rackoff 
[LMR83] and progressed with the contributions of [Ya86, BG89, GL90]. 


GMW-GaMES. A more general notion for security has been introduced by Goldreich, Micali 
and Wigderson [GMW87]. They consider secure protocols as implementations of abstract, but 
computable, games of partial information. Informally, ingredients of such an n-player game are an 
arbitrary set of states, a set of moves (functions from states to states), a set of knowledge functions 
(defined on the states), and a vector-valued outcome function (defined on the states) whose range 
values have as many components as there are players. The players wish to start the game by 
probabilistically selecting an initial state globally unknown to every one. Then the players take 
turns in making moves. When it is the turn of player 7, a portion K(5) of the current global state 5 
must be privately revealed to him; here K denotes the proper knowledge function for this stage 
of the game. Based on this private information, player i secretly selects a move yu, thereby the 
new, secret, state must become p(S). At the end of the game, each player privately learns his own 
component of the outcome function evaluated at the final state. 

[GM W87] envisioned a notion of security which would mimic the abstract game in a “virtual” 
manner: states are virtually selected, moves act on virtual states, and so on. We will refer to their 
notion as GMW-games. Again putting aside how this can be achieved, let us point out an additional 
aspect of their notion. Namely, in a GMW-game, bad players cannot disrupt the computation at 
all by quitting early. (This condition can indeed be enforced whenever the majority of the players 
are honest.) 


OTHER PRIOR WORK. Several noteworthy variants of Y-evaluation and GMW-games have been pro- 
posed, with varying degrees of explicitr>ss and care. These definitional ideas include, most notably, 
the work of Galil, Haber and Yung [GHY87], Chaum, Damgard and van de Graff [CDG87], Ben-Or, 
Goldwasser and Wigderson [BGW88], Chaum, Crépeau and Damgard [CCD88], Kilian [Ki89], and 
Crépeau [Cr90]. 


CONCURRENT WORK. Early in our effort we told our initial ideas (like merging privacy and cor- 
rectness) to Beaver, who later pursued his own ones in [Be91a, Be91b]. 

Later, we collaborated with Kilian in developing definitions for secure function evaluation. 
This collaboration was enjoyable and profitable. Its fruits are described in [KMR90], and will be 
discussed in Section 3.7 

Concurrently with the effort of [KMR90], Goldwasser and Levin [GL90] independently proposed 
an interesting approach to defining secure function evaluation. 


1.4 Critique of These Definitions 


Definitions cannot, of course, be “wrong” in an absolute sense; but we feel that all previous ones 
were either vague, or not sufficiently general, or considered “secure” protocols that should have not 
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been called such at a closer analysis. We thus cheerfully decided to clarify the intuitive notion of 
secure computation. Little we knew that we had taken up a two-year commitment! 
Let us very briefly critique some of the mentioned work. 


Y-EVALUATION. Though Yao should be credited for presenting his notion with great detail!, in our 


opinion his ideas do not fully capture the fundamental intuition of secure computation, leading to 
several difficulties. 


Blind input correlation. One of these difficulties we call “blind input correlation.” Namely, a two- 
party Y-evaluation, while preventing a bad player from directly learning the good player’s input, 
might allow him to choose his own input so to be correlated with the good player’s. For example, it 
is not ruled out that, whenever the good player starts with secret input z, the bad player, without 
finding out what z was, can force the output to be, say, y = f(z,z) (or y = f(z,—-z), or ...). In 
some context, this correlation may result in (what would be considered by most people) a loss of 
security.” 


Privacy/correctness separation. Y-evaluation considers privacy and correctness as individual con- 
straints and, though with a different terminology, considers secure a protocol that is both private 
and correct. Indeed, privacy and correctness are the fundamental aspects of secure computation, 
but, as we point out in the discussion of Chapter 3, the logical connective “and” does not blend 
them adequately together. The negative effect of this definitional approach is thus considering 
secure some protocols that are not such, at least according to our intuition. 


GMW-cGaMES. GMW-games are most general and powerful, and they are endowed with very 
strong intuitive appeal. The weakness of [GMW687] is in not providing full help in turning this 
intuition into a successful formalization. Indeed, several wrong choices could still be made from 
the level their definition was left at. Additionally, their notion was being developed for protocols 
possessing a very particular structure. Namely, the notion of security was tailored for protocols 
that would first perform an initial committal phase, and would then perform computation on these 
committed inputs. While their algorithmic structure proved to be very successful (indeed, all 
subsequent protocols for secure computation share it), it should not be embedded in the definition 
of our goal. (Indeed, the tendency of defining security as a property of a specific protocol —or class 
of protocols— is wide-spread in the prior literature.) 


CONCURRENT WORK. Concurrent work does not suffer from this drawback, but has other short- 
comings. Beaver [Be91a] does not blend the various goals for a secure protocol, but treats them as 
separate requirements, as Yao first did and incurring in the same type of difficulties. (This same 
author has presented a new paper on this same subject to Crypto ’91, concurrently with ours, but, 
not having yet seen it, we cannot comment on it.) As for the work of Goldwasser and Levin, we 
believe that, as we point out in the discussion of Section 4, in a computationally bounded setting, 
it may be difficult to design protocols proven secure according to their definitions. 


This precision, however, was made heavier from lacking more modern constructs for discussing these issues, like 
the notion of a simulator developed by Goldwasser, Micali and Rackoff [GMR89]. 

?Let’s see what its effects might be on some of the discussed secure-computation problems. Consider solving the 
digital voting problem by Y-evaluating the tally function; for simplicity, let there be only two candidates to vote for. 
Then the bad players —though ignoring the electoral intentions of a given good player— might succeed in voting as 
a block for the opposite candidate. Should we consider this a secure election? We believe not. Similarly, trying to 
solve the independent announcement problem by Y-evaluating the “concatenation” function (i.e., the function that, 
on inputs z1,...,2n, returns the single value z:#...#2n), a bad player might always succeed in announcing the 
same value as a given good player. Indeed, a poor case of independence! 


1.5 Our Definitions 


Our notion of secure computation solves the above difficulties, and other ones as well. We plan to 
build up our definition in two stages. First, as our alternative to Y-evaluation, we define secure 
function evaluation, to which this paper is devoted. Our notion is quite powerful and expressive; 
for instance, the first three secure-computation problems of Subsection 1.1 are straightforwardly 
solvable by securely evaluating the proper function. After developing secure function evaluation, 
we hint how this notion can be successfully extended to that of a secure game, our way of fully 
specifying GMW-games. (The present paper is already quite long, and a different one should be 
devoted to a detailed treatment of this extension. Also, the present treatment restricts its definitions 
to there being three or more players.) Secure games capture, in our opinion, the very notion of 
secure computation. Quite reassuringly, all six problems of Subsection 1.1 are straightforwardly 
solved by “playing” a secure game. 

The basic intuition behind secure function evaluation is the same one put forward, in quite a 
different language, by [GMW87]. In essence, two scenarios are considered: an ideal one in which 
there is a trusted party helping in the function evaluation, and a realistic one in which the trusted 
party is simulated by running a protocol. Security is a property of a realistic evaluation, and consists 
of achieving “indistinguishability” from the corresponding ideal evaluation. While remaining quite 
informal, let us at least be less succinct. 


IDEAL FUNCTION EVALUATION. In an ideal function evaluation of a vector-valued function f there 
is an external trusted party to whom the participants privately give their respective secret inputs. 
The trusted entity will not divulge the received inputs; rather, it will correctly evaluate function f 
on them, and will privately hand component ? of the result to party i. An adversary can interfere 
with this evaluation as follows. At the very beginning, before any party has given his own input to 
the trusted party, the adversary can corrupt a first player and learn his private input. After this, 
and possibly based on what she has just learned, the adversary may corrupt a second player and 
learn this input, too. This continues until the adversary is satisfied. At this point, the adversary 
chooses alternative, fake inputs for the corrupted players, and all parties give the their inputs 
to the trusted authority—the uncorrupted players giving their initial inputs, avd the corrupted 
players giving their new, fake inputs. When the proper, individual outputs ha, been returned 
by the trusted party, the adversary learns the value of the output of every corrupted player. The 
adversary can still corrupt, one by one, additional players, learning both their inputs and outputs 
when she does so. 

It should be noticed that in such an ideal evaluation the adversary not only learns the inputs of 
the players she corrupts, but by choosing properly their substitutes, she may learn from the final 
result quite a bit about the other inputs as well. 


IDEAL VS. SECURE FUNCTION EVALUATION. While the notion of an ideal function evaluation has 
been essentially defined above, formalizing the notion of a secure function evaluation is much more 
complex; we will do it in the next few sections. Here let us just give its basic intuition. To begin 
with, there no longer is any trusted party; the players will instead try to simulate one by means of 
a protocol. The adversary can still corrupt any ¢ players, but this time a corruption will be much 
more “rewarding.” For not only will she learn the private inputs of corrupted players, but also 
their current computational state in the protocol (and a bit of additional information as well). She 
will receive all future message addressed to them and she will get control of what messages they 
are responsible for sending out. 

Given the greater power of the adversary in this new setting, it is intuitively clear that a protocol 
for function evaluation cannot perform “better” than an ideal function evaluation; but it can do 
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much worse! Roughly said, a secure function evaluation consists of simulating every important 
aspect of an ideal function evaluation, to the mazimum extent possible, so that a secure protocol 
does not perform “significantly worse” than the ideal protocol. 


Setting the stage of security in terms of the above indistinguishability is an important insight 
of the [GMW687] work. We also follow their approach, but our notion of indistinguishability is a 
bit more liberal —that is, as we shall see, it crucially allows a bit more of interaction. The main 
difference with their work, though, and the real difficulty of ours, is not so much in the spirit of the 
solution as in properly realizing what “maximum possible” should mean, and identifying what are 
the important features, implicit (and perhaps hidden) in an ideal function evaluation that should 
(and can!) be mimicked in a secure function evaluation. 


1.6 Key Features of Our Definitions 


Let us now highlight the key features of our definitions. These we distinguish as choices and prop- 
erties. The former are key technical ideas of our notion of security. The latter are key desiderata: 
each one is a condition-sine-qua-non for calling a protocol secure. Notice, though, that we do not 
force these necessary conditions into our definitions in an artificial manner; rather, we derive them 
naturally as consequences (hence the name “properties”) of our notion of security, and thus of our 
technical choices. 


Key Choices 


_ BLENDING PRIVACY AND CORRECTNESS. Secure protocols are more than just correct and private. 
Simply requiring simultaneous meeting of these two requirements leads to several “embarrassing” 
situations. In a secure protocol, correctness and privacy are blended a deeper manner. In particular, 
privacy —a meaningful notion all by itself— is taken to mean that the protocol admits a certain type 
of simulator, and correctness is a concept which we define through the same simulator proving the 
protocol private. This merging of privacy and correctness avoids calling secure protocols those which 
clearly are not, and is a main contribution of this paper, as well as one of our first achievements 
in the course of this research. We are pleased to see that our idea has been adopted by other 
researchers in the area. 


ADVERSARIAL AWARENESS. In the ideal evaluation of f, not only is there a notion of what inputs 
the adversary has substituted for the original ones of the corrupted players, but also that she is aware 
of what these substituted inputs are! Similarly, she is aware of the outputs handed by the trusted 
party to the corrupted players. We realize that this is a crucial aspect of ideal evaluation, and 
thus one that should be preserved as closely as possible by secure evaluation. Indeed, adversarial 
awareness is an essential ingredient in obtaining the crucial reducibility property discussed below. 


TIGHT MIMICRY. Our definition of a secure protocol mimics the ideal evaluation of a function f 
in a very “tight” manner. (For those familiar with the earlier definition of zero knowledge, the 
definition of security relies less on “global” properties of ensembles of executions and more on 
individual executions.) In each particular run of a secure protocol for evaluating f, one may 
“put a finger on” what inputs the adversary has effectively substituted for the original ones of the 
corrupted players; when in the computation this has happened; what the adversary and the players 
get back from the joint computation, and when this happens; and these values are guaranteed 
(almost certainly) to be exactly what they should be — based on f, the inputs the adversary has 
effectively substituted, and the inputs the good players originally had. 


Key Properties 


MODEL INDEPENDENCE. As we said a secure protocol is one that “properly” replaces the trusted 
external party of ideal evaluation with exchanging messages. There are, however, several possibil- 
ities for exchanging messages. For instance, each pair of participants may be linked by a secure 
communication channel (i.e., the adversary cannot hear messages exchanged by uncorrupted peo- 
ple); alternatively, each pair of players may have a dedicated, but insecure, communication channel; 
else, the only possible communication may consist of broadcasting messages, and so on. Though 
for ease of presentation we develop our notion of security with respect to a particular, underlying 
communication model, our notion of security is essentially independent of the underlying communi- 
cation model. Indeed, we prove that the existence of secure protocol in one model of communication 
entails their existence in all other “reasonable” models. This proof is highly constructive: we show 
that, for any two rich-enough communication models, there exists a “compiler” that, given a pro- 
tocol secure in the first model, generates a protocol for the same task which is secure in the second. 
(Interestingly, the proof, though often considered folklore, turned out to be quite difficult!) 


SYNTACTIC INDEPENDENCE. Our definition of security is independent of the “syntax” in which a 
protocol is written. Designing a secure protocol is easier if one adopts a syntactic structure a la 
[GMW87]; that is, having the parties first execute a “committal phase” in which they pin down 
their inputs while keeping them still secret? and then they compute on these committed inputs. 
A different type of syntactic help consists of assuming that a primitive for securely computing 
some simple function is given, and then reducing to it the secure computation of more complex 
functions. This also simplifies the design of secure computation protocols (and actually presupposes 
that secure protocols enjoy the reducibility property we discuss below.) While it is alright to use a 
right syntax to lessen the difficulty of designing secure protocols, we insisted that our definition of 
security be independent of any specific syntactic restriction for a protocol to be called secure. (Of 
course, though we insist at remaining at an intuitive level here, being secure is itself an enormous 
restriction for a protocol, but of a different nature.) 


INPUT INDEPENDENCE. There is yet a third, and crucial, type of independence property. In the 
ideal evaluation of a function f, the fake values the adversary chooses are completely independent 
of the values held by uncorrupted players. Of course, a secure protocol should have this property 
too, as closely as is possible. (It is a rather subtle matter how to state this goal satisfactorily.) After 
the proper definitions are in place, we show that our defi: ‘tion of security captures independence 
in an eztremely strong sense—not by “adding it in” as a desired goal, but, rather, by it being a 
provable property of any secure protocol. - 


REDUCIBILITY. Reducibility has always been a key desideratum. Let us describe this goal. Suppose 
you have designed a secure protocol for some complicated task—computing some function f, say. 
In an effort to make more manageable your job as protocol designer, you assumed in designing the 
protocol that you had some primitive, g, in hand. You proved that your protocol P# for computing 
f was secure in a “special” model of computation — one in which an “ideal” evaluation of the 
primitive g was provided “for free.” One would want that you obtain a secure protocol for f by 
inserting the code of a secure protocol for g wherever it is necessary in P* that g be computed. 
This key goal for any “good” definition of security is surprisingly difficult to obtain, particularly 
if one adopts the most natural and innocent-looking notion of adversarial awareness (namely, the 
result of applying a fixed algorithm to the adversary’s entire computational state). Our notion of 


3This secret commitment is called verifiable secret sharing, a notion introduced by [CGMAS85]. For a precise 
definition and worked out example see [F M90] 
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security ensures reducibility; in fact, this has been one of the main driving forces in shaping our 
definitions. 


1.7 How to Read This Paper 


GENERAL ORGANIZATION. The paper is divided up into five chapters. After this (1) introduction, 
one is (2) a chapter describing protocols, then (3) one describing secure protocols, (4) a chapter on 
complexity issues and the computational security, and, finally, (5) a chapter on properties of secure 
protocols. 

This release is a preliminary report. Though chapters (1)-(3) are getting close to their final 
form, chapters (4) and (5) are rather incomplete and contain historical baggage in their notation, 
outlook, and proofs. 


SIMPLIFYING ASSUMPTIONS. In order to simplify the presentation of our notion of security, we 
initially makes a number of simplifying assumptions. In particular, as our development begins we 
initially assume the following: 


1. First, that the players and our adversaries have no past and no destiny but to try to compute 
some given function. Thus each party brings into the collaborative computation of a function f 
only his input z;, and the adversary brings into the collaborative computation no special 
information whatsoever. This disregard for players’ and the adversary’s history is rectified in 
Section 3.5. 


2. We assume that there are only a fized number of parties participating in the protocol. This 
restriction is relaxed in Section 3.6.1. 


3. We assume that the goal of these players is to collaboratively compute some particular finite 
function. A finite function is a map from strings of some fixed length @ to strings of some 
fixed length, /. This restriction is relaxed in Section 3.6.2. 


4, We assume that a secure protocol for evaluating a function takes some particular number of 
rounds, R. This number may be thought of as a constant, or, more generally, as a polynomial- 
time computable function of the “common input.” A protocol so restricted is called a fized- 
round protocol. In Section 3.6.3 we relax the restriction that our protocols are fixed-round 
protocols. 


5. We initially take our goal to be an information-theoretic standard of security. What is more, 
hough there are complexity-issues which should be dealt with even for information-theoretic 
security, we ignore them. Complexity-theoretic extensions and modifications to our definitions 
are described in Chapter 4. 


Because of some of these, the notion of security initially developed (Definition 3.10) fails to have 
some of the properties one would expect of a secure protocol, and it fails to illustrate the full power 
of our adversaries. Only after accommodating the first three of these extensions can we maintain 
that a reasonable notion has been achieved (Definition 3.15). Nonetheless, the “stripped-down” 
notion is meaningful, and describing it first and then specifying how the definition is modified 
highlights the importance of a variety of issues. 

In this paper we aim at achieving solely what we believe should be the absolute minimum 
notion of security. This should encompass “input independence” and “reducibility.” Indeed these 
are properties both desirable and achieved by our definition, as we show in Chapter 5. Protocols 
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have many important angles to them. Among these are “economicity of resources” and “fairness,” 
whose investigation is already under way. We do not deal with these and other more sophisticated 
notions in our paper. To avoid that the field would outpace its foundations, we believe that a firmer 
understanding of basic security should come first. 

Those who believe that what we consider an absolute minimum is actually “too much” (e.g., 


those who think that security should be defined without guaranteeing reducibility, say) may find 
in section 3.7 more general notions outlined. 


12 


2 Protocols and Adversaries 


In this section we describe the execution of protocols—programs which are run by a collection of 
communicating players. Specifying how a protocol runs involves describing not only what happens 
when all the players perform flawlessly, but in describing, too, the manner in which they may fail 
to perform their specified instructions, and what effect this has on the execution. 

First we describe how a fault-less network operates. Afterwards, we consider the possibility 
of some players becoming “bad”—that is, of deviating from their prescribed instructions. Several 
questions immediately arise concerning the capabilities of these bad players. 


ADVERSARIES. First among them is: how powerful should we let these bad players be? In some 
scenarios the only natural way for a processor to deviate from a protocol is by ceasing all commu- 
nications, such as in the case of a computer “crash.” Alternatively, processors may start sending 
messages “at random,” corresponding, perhaps, to having some short-circuited register. If people 
are behind their processors, it is safer to consider more “malicious” deviations. This possibility, 
clearly subsuming the previous ones, is the one we focus on. Our goal is in fact reaching the 
strongest, natural notion of security, so that a protocol satisfying our definitions may be safely and 
easily used in any natural context. We thus allow bad players to deviate from their prescribed 
instructions in any way—the only constraint being that the number of bad players may be limited 
to a certain fraction of the total. (We will later consider the case in which bad players are limited 
to being able to perform “reasonable” computational tasks, as well.) We also allow bad players to 
secretly cooperate with each other. Actually, to guarantee their “perfect cooperation,” we envisage 
a single agent, the adversary, who, during an execution of a protocol, may corrupt and control 
players. 

An equally important question is: when can the adversary corrupt players? One possibility is to 
consider a static adversary, one who can choose and corrupt a subset of the players only at the start 
of a protocol. Since any real adversary may be expected to make an effort to corrupt those players 
whose corruption would be most beneficial to her, a better possibility is to consider a dynamic 
adversary, one capable of corrupting players at arbitrary points during the execution of a protocol, 
based on the information acquired from previous corruptions. Such an adversary s provably more 
powerful than a static one (see Section 3.6.5), and security with respect to a dynamic adversary is 
both harder to achieve and harder to properly define. The adversary we consider is dynamic. 


COMMUNICATION MODEL. Assuming such a strong adversary makes our definition of security much 
more meaningful. On the other hand, given that secure protocols are non-trivial to find, we at least 
make them easier to write by providing a generous communication model. In essence, we allow each 
player both to privately talk to any other player (that is, to speak over a “private communication 
line”), and to talk “aloud,” so that all players will hear what is said and know who has said it (that 
is, to speak over a dedicated communication line that is monitored by all the other players). 

While our notions and theorems are stated in this chosen chosen communication model, we 
emphasize that, as with all important notions, secure computation is essentially independent of 
the particulars of the selected model. Indeed, for the notion of security we develop, essentially a 
syntactical replacement of adversaries and networks in our definition by respective, weaker versions 
of them yields the corresponding, right notion of security in the modified framework. 
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2.1 Protocols 
2.1.1 Informal description 


THE GENERAL PICTURE. Protocols are the instructions which players follow in order to accomplish 
some task. A collection of players connected by some communication mechanism is said to form 
a network. Each player of a network has a string, called his computational state, and the effect of 
the protocol is in updating these strings. At the beginning of a protocol this string should encode 
a player’s private input. 

Computational states are updated either as a result of local computation, or as a result of 
interacting with other players by exchanging messages. As we shall see in detail, the ordering of 
these events is tightly controlled. In fact, our protocols operate in rounds. A round consists of 
having all players perform their local computation and then sending messages to all other players. 
Once all these messages have been delivered to the proper players, the next round begins. This 
process repeats a fixed number of times. 

Intuitively, local computation consists of applying a probabilistic function to a player’s compu- 
tational state. Still, we find it convenient to distinguish between probabilistic and deterministic 
aspects involved in local computation. Namely, a player computes locally in two ways. First, he 
can replace his own computational state by its image under some (deterministic) function; in fact, 
a protocol is regarded as being precisely this function. Also, a player may append to his compu- 
tational state a uniformly distributed random bit—a process called “flipping a coin.” This models 
that fact that a computing device with suitable hardware can obtain “random” bits. Such random 
bits are crucial for achieving security in our sense. Which of these two activities a player wishes to 
perform is indicated in his computational state, according to some fixed conventions. Alternatively, 
the computational state may indicate that the player’s local computation is over for the current 
round, and all his messages are ready to be sent out. 

Interaction with other players occurs once all the players finish their local computation for the 
current round. At this time, each player has a computational state which determines his broadcast 
message, which is a string to be delivered to everyone, as well as a set of private messages, each 
of which is to be delivered to a specified recipient. As we shall specify shortly, these messages will 
be delivered by appending to each player’s state the various messages he is entitled to, making it 
clear what was received from whom. 


ADDITIONAL CHOICES. While notions such as rounds are central to the idea of a synchronous pro- 
tocol and would likely be reflected in any formalization of the execution of a protocol, various other 
choices in our formalization reflect a more individual taste. For instance, while protocols, players, 
and networks are all ideas with strong intuitive meaning, we only formalize protocols. Players and 
networks are thought of as “virtual” objects, not directly represented in the formalism and primar- 
ily useful for the language of discourse they provide. Intuitively, any “computing device” can play 
the role of a player, and any “communication mechanism” can play the role of the network. But 
a protocol is mathematical object, natural to define and independent of any particular computing 
device or communication mechanism designed to execute it. 

Another personal choice is our formalization of a protocol as a single program. Conceptually, 
each player i runs his own program, P;, directing the evolution in time of his computational state. 
However, we consider each player as running the same program, P. Such a program is made 
specific to the player who runs it simply by specifying a player’s identity in his initial computational 
state. This makes a protocol a finite-size object instructing each player how to behave, however 
many of them there are. Clearly this viewpoint entails no loss of generality when the number of 
players is fixed—you could always imagine that a protocol P begins by saying, “if you are player 1, 
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execute P;”—and the viewpoint ensures, when the number of players is not regarded as fixed, that 
a protocol always has a finite description. 

To describe protocols more formally, we have drawn a distinction between the computation 
which a protocol P directs, and the other, “syntactic” components needed to compactly specify 
how a protocol runs. These syntactic functions direct whether it is time to apply the function P, 
or time to flip a coin, or time to end the round’s activities; and they specify what messages a player 
means to broadcast and which ones he intends to deliver privately to whom. 

To facilitate discussing complexity issues later, a protocol P is regarded as a function not only 
of a player’s computational state, but also of a separate string called the common input, which is 
known by everyone. 


2.1.2 Formal description 


NotTaTION. An alphabet is a finite set. We will only use the alphabet {0,1}. A string is a 
finite sequence of characters from some alphabet, and an infinite string is an infinite sequence of 
characters over some alphabet. If z and y are strings, ry denotes their concatenation. A language 
is a set of strings. 

We define {0,1}” as the language of strings of length n, and {0,1}" = U,, {0,1}” as the set 
of all strings. We let {0,1}° denote the set of infinite binary strings. The empty string (i.e., the 
length-0 sequence of characters) is denoted by A. If we write z € {0,1}" where z is apparently 
not composed of characters of the alphabet {0,1} (e.g., z = 11+0), then it is understood that the 
string z is encoded over {0,1} in some natural manner. 

The set of nonnegative integers is denoted N = {0,1,2,...}. If a and 6 are integers, a < b, we 
let [a..b] denote the set of integers between a and 4, inclusive. By [a..co] we denote the set of all 
integers greater than or equal to a, together with a point “co”. 


DEFINITION OF A PROTOCOL. We reiterate that we are first describing a protocol for a fixed 
number of players; later we discuss protocols for arbitrary numbers of players. We also note that 
the phrases beneath the underbraces should be considered as suggestive terminology, not part of 
any formal definition. 


Definition 2.1 An R-round, n-party protocol is a Turing-computable function 


P: {0,1} x {0,1} > £0,1}°. 
— ——— moe 


common current new 
input state atate 


A protocol syntactic function is any of the following Turing-computable functions: 


¢ anext-action function, VN: {0,1}° — {compute, flip-coin, round-done} 
— on 


current action to take 
state 


e a broadcast-message function, M: {0,1} — {0,1}° 
—_—_—— —=—— 


current broadcast 
state message 


e a private-message function, m: {0,1} x [l..n] — {0,1} 
——— —— cn aoe? 


current identity of private 
state recipient message 


NotaTIONn. In place of m(s;,7) we write m;(s;). 
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2.1.3. Remarks 


RECOVERABILITY OF COIN TOSSES. As we have said, when a player flips a coin the outcome is 
appended to his computational state. This process can be repeated as many times as it is deemed 
sufficient. Then the protocol function P is applied to this augmented computational state, a new 
state results, and the coin flips may or may not be recoverable it. Some protocols “record” their 
coin tosses in the new state, others do not (though some information about these coin tosses may 
still be inferable from the new computational state). 


THE SYNTACTIC FUNCTIONS. These specify how a protocol P directs the updating of player’s 
computational state, effecting the computational states of other players in the process. As such, 
we might have considered a protocol to be the five-tuple (P,N,M,m) consisting of the protocol 
algorithm proper and the collection of syntactic functions. However, we choose instead to take the 
syntactic functions to be fired functions, good for any protocol. This way, for example, protocols 
can more easily be composed with one another: there is no danger that two protocols employ 
different conventions on how processors communicate, say. 

Though particular maps, we have not actually specified the syntactic functions since the con- 
ventions chosen for defining them are not important. Each function should specify its range value 
in a natural and simple manner from its domain value. For example, with “(”, “)”, “(”, “)”, 
“*”, and “,” all being formal symbols, we might say that if computational state s; does not con- 
tain the symbol “*” but it does contain one and only one occurrence of a substring (1/) then 
N(s;) = flip-coin if 7 = 2, N(s;) = round-done if 7 = 3, N(s;) = protocol-done if 7 = 4; in all 
other cases, V(s;) = compute; if s; contains one and only one occurrence of a substring (4), then 
M(s;) = ; otherwise, M(s;) = A; if s; contains one and only one occurrence of a substring (1, y1;), 
for j € [1..n], then m;(s;) = yj; otherwise; m;(s;) = A. 


2.2 Executing Protocols in the Absence of an Adversary 
2.2.1 Informal description 


The syntactic goal of executing a protocol is transforming the players’ initial computational states 
to a set of final computational states. Besides the common input and the initial computational 
states, this transformation depends on the particular coin flips made by each player. This naturally 
leads to the notion of a player configumtion, which records both a player’s computational state and 
his “future coin tosses.” That is, each player, at the beginning of the protocol, has associated to 
him an infinite string of bits, each selected with uniform probability. When the player flips a coin, 
he reads and strips off the first bit in this sequence. 

In absence of an adversary, the common input and the players’ initial configurations completely 
determine the execution of a protocol. In the formalism below, we recursively express how these 
configurations progress from round to round. Here is the general idea. 

Each player ¢ begins round r in some configuration C7, and ends with some configuration C7. 
This transformation is not done in one step. Rather, by flipping coins and computing, the player 
goes through a sequence of micro-rounds, 0,1,2,.... (The micro-round p is written as a second 
superscript to the quantity of interest.) In some cases there may be an infinite sequences of micro- 
rounds without completing the round (as when, being very unlucky, a player tries to select one out 
of three possibilities with uniform probability). Normally, however, there will be a finite number g,, 
of micro-rounds before the next-action function evaluates to “round-done.” Accordingly, player « 
will begin round r in some configuration C?° (= C1), and end it in some configuration C;*" (= C7). 
For every player i, C{"*’” is determined from all of the configurations {Cj°"} by evaluating the 
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broadcast-message function and private-message function on them, and appending to each C/**" its 
proper message subset. 


2.2.2 Formal description 


NotaTIONn. When a symbol denotes a string or an infinite string, use of the same symbol with a 
subscript denotes the indicated character. This convention holds even if the symbol denoting the 
string already bears a subscript. For example, if r; is a string or an infinite string, then r,, is the 
first character of r;. 

Two other notes. Symbols such as {#,}, *,e,m}, which appear here or elsewhere, are all just 
formal punctuation symbols. Also, the character r, below, is somewhat overworked: with a sub- 
script 2, it indicates player i’s random string; as a superscript, it indicates the round number. This 
should cause no confusion. 


PLAYER CONFIGURATIONS. These should capture enough information to allow a convenient recur- 
sive formalization of the execution of a protocol, as player configurations evolve from microround- 
to-microround and round-to-round. 
Definition 2.2 A player configuration (s;, 7;) is an element of {0,1}" x {0,1}. 

— —— 

player's future 


state coins 


CONFIGURATION SEQUENCES. An R-round, n-party protocol P generates from a common input, c, 
and n initial player configurations, (C?°,...,C0°), a sequence of configurations {C;’: i € [1..n],r€ 
[0..2],0€N}, which we now describe. Sometimes, one or more of these configurations may fail to 
be defined by the recurrences below. If this happens, the protocol is said to have diverged. 

Fix the notation 


Cy? = (8)°, 47°) 
for player configurations, and let 9;, denote the least number such that V/(s;°") = round-done (if 
such a number exists). Define 
Mr = M(s%") — and 
mi; = m;(s;°") 
for what processor i: broadcasts in round r and sends to processor j in round r, respectively. Let 


Mi = Mi#---*#Miamj,«---#m) 


ni 


be the actual messages (public and private) sent to processor i in round r. (These will not be 
received until the beginning of round r +1.) Define C7? = C}° = CQ° for all p € [l..co) and 
i € [1..n]. Then, for r > 1, the players’ configurations progress as follows: 


(P(e, 377), 73"), if N(s;°) = compute 
Crt) = d (slant? rl rle...) if N(s1°) = flip-coin 
Ci’ if N’(s;”) = round-done 
pone (si *Mj, rier) ifr>0 
Ci ifr=0 
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EXECUTING PROTOCOLS. An initial configuration of the network is identified by a tuple (Z,c, 7) 
specifying the player’s private inputs z,,...,Z, € {0,1}", the common input c € {0,1}", and the 
players’ coins 11,...,7 € {0,1}°. An initial configuration of the network determines an ezecution 
of the n-party protocol P. This execution is the sequence of configurations {C;’} generated by P 
when the initial configuration of party i is taken to be C/° = (a;{i, r;), player i’s coins are r;, and 
the common input is c¢. 

The set of executions of P with common input c, private inputs 2,,...,2,, and all possible coin 
sequences r1,...,% enjoys a probability measure by endowing each execution with the measure 
induced by taking each bit of each r; to be selected uniformly and independently. In the absence 
of an adversary, ezecuting a protocol P with common input c and private inputs 2;,...,2,, means 
sampling according to this probability distribution. 


ADMISSIBLE PROTOCOLS. As we have said, a protocol may diverge (when a player repeatedly flips 
coins and applies the protocol function P without ever ending a round). We are not interested in 
protocols for which this happens.* A protocol is called admissible if, for any common input and 
any initial player configuration, it does not diverge. From now on, all protocols are assumed to be 
admissible. Forcing a protocol to flip at most a fixed number of coins per round (a number which 
depends only on the common input, say) is certainly a way to guarantee its admissibility. 


PLAYER’S VIEW. The computational state of a player need only record what he requires to continue 
his, and therefore prior computational states might or might not be inferable from the current 
computational state. It is useful to introduce view, a notion formalizing this “history” of prior 
computational states. 

In a protocol execution, the round-r view of player ¢ is the string ht = (37°, sf!,..., 3°"). His 
view through round r is defined as Hf = (c, h?,h},...,h£), while the view of player i from an 
R-round protocol is H?. 


2.2.3 Remarks 


MORE ON COIN TOSSES. Whether or not a protocol keeps explicit record of the -oins tossed (see 
remark 2.1.3), it is still meaningful to speak about notions such as “the coins flip,ed by the first 
player during a particular round in an execution of a protocol.” 


SIMULATING ROUNDS. The organization of the computation in rounds, though purely conceptual, 
can be simulated in the real world without relying on perfect synchrony. For instance, in a computer 
network one may not be able to guarantee simultaneous delivery of messages nor access to a global 
clock. Nonetheless, it may be reasonable to assume that every message sent will arrive within five 
minutes of when it was sent, that the local computation of every processor can be completed within 
half an hour, and that each processor’s clock knows the time of day within five minutes. In this 
case, the round structure can be simulated by instructing every processor to send its messages on 
the (local) hour, and start its local computation, using all the newly received messages, at a quarter 
past the hour. 

As can be appreciated such a simulation, rounds are often an expensive resource. Since the time 
allocated for simulating each round should be sufficiently generous, so to be sure that all messages 
will be received and all local computation done, it is important to design protocols that use few 
rounds. 


* Alternatively, we could say “we are not interested in protocols for which this happens with positive probability.” 
This relaxation would slightly complicate the statement of some later definitions, but is otherwise immaterial. 
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THE VOID ROUND. We have established the convention that a protocol begins with the players 
executing a “dummy” round, round 0. During this round, “nothing happens.” The presence of 
the void round facilitates bringing the adversary into the model of computation in a manner which 
allows for clean protocol composition. 


2.3. Adversaries 
2.3.1 Informal description 


An adversary is a device capable of interacting with the participants of a network in a prescribed 
way. For convenience of discourse, we will adopt gender conventions: a player, “he,” and the 
adversary, “she.”* 

The options of an adversary are greater than those of a player. Like the players, she can 
compute, flip coins, send and receive messages. Her additional feature is her ability to corrupt 
players in the execution of a protocol. Though we postpone, for a bit, the details of her interaction 
with the players, it is necessary to understand right off that once a player 2 is corrupted, it is the 
adversary who will receive messages sent to 2 and send messages on his behalf. 

Our aim for now is to describe the adversary as a “gadget.” Like the players, this gadget has 
associated to it a collection of syntactic functions. The adversary’s next-action function N indicates 
what action she wishes to perform next; her broadcast-message function M indicates what she 
will broadcast on behalf of corrupted players; and her private-message function ™m indicates what 
message she will send privately to each player, on behalf of each corrupted processor. 


2.3.2 Formal description 
Definition 2.3 An adversary for an n-party protocol is a function 


A: {0,1}" x {0,1}" > {0,1}. 
ne —— ew wae! 


common current new 
Input state state 


An adversary syntactic function is any of the following functions: 


e anext-action function, V: {0,1}" — {compute, flip-coin, corrupt, ,..., corrupt, ,round-done } 
en pore 


current 
state 


e a broadcast-message function, M: {0,1}° x [l.n] — {0,1} 
nd nd ——— 


current corrupted broadcast 
state player message 


e a private-message function, m: {0,1}" x [l..n] x [l..n] — {0,1} 
— ne — a —— 


current corrupted identity of private 
state player recipient message 


NoTATION. In place of M(s,,i) and m(s,,i,j) we will write M;(s,) and 1,;(s,), respectively. 


5 Justification for gender conventions judiciously relegated to an unpublished manuscript. 
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Player’s round R 


Adversary’s round R 


Figure 1: An R-round execution of a protocol with the adversary. The player’s 0 round is a round 
in which there is not activity. Such rounds will be marked with a “«”.) 


2.3.3 Remarks 


Again, we do not explicitly specify the syntactic functions since the particular conventions selected 
for them is irrelevant to further discussion. All that is important is that each function specifies its 
range value in a natural and simple manner from its domain value, as with the syntactic functions 
associated to the players of a network. 

As with a protocol, the first component in A’s domain is the common input. Though this could 
be considered as an unnecessary component—it could be encoded in the adversary’s initial compu- 
tational state—we make a separate argument of it to facilitate, later on, dealing with computational 
complexity. 

Note that, while a protocol must at least be computable, no similar assumption is made of 
an adversary; an adversary which is, say, an arbitrary function, with no finite description, is a 
perfectly good adversary. Possible restrictions on the power of an adversary will be investigated in 
Chapter 5. 


2.4 Executing Protocols in the Presence of an Adversary 
2.4.1 Informal description 


ALTERNATING ACTIVITY. Think of an adversary A as an abstract machine interacting with the 
participants of a network in a prescribed way. This way entails the players and the adversary 
alternating periods of activity, as suggested by Figure 1. 

In the beginning, all of the players are good, and so they remain unless the adversary corrupts 
them. While the players compute, the adversary is quiescent. But once all of the still-good players 
have finished their local computation, they effectively go to sleep, and A is awakened. She is active 
for a while—computing locally and possibly corrupting additional players—until she has finished, 
for the time being, and goes to sleep. Then the players execute again. The players and the adversary 
continue alternating periods of execution in this way, until the players complete their last round, R. 
At that point, the adversary is given one last round of activity, and then the protocol execution is 
said to be over. 


AN ADVERSARY ROUND. When an adversary begins a round of her activity, she is given certain 
information. Namely, she is handed the messages that still-good players have just broadcasted, 
plus the messages the still-good players just transmitted to already-corrupted players. 

After some local computation, the adversary may choose to corrupt some players. This she 
can do in a dynamic way. When corrupting a player i in round r, the adversary learns some 


20 


information about him, his exposed state, of, which will be described momentarily. Then, based on 
this information, still within the same round, the adversary can corrupt, one at a time and exactly 
as before, additional players, until she does not want to corrupt any more of them. At this point, 
the adversary composes all out-going messages from the bad players to the good, and it is these 
messages (together with the messages sent by good players) which will be delivered to the players 
in the next round. 

In our formalization, an adversary round is divided into a sequence of micro-rounds, just as 
player rounds were. As her micro-rounds progress, the adversary computes, flips coins, and corrupts 
players. Though we find it convenient to adopt a formalism in which the players execute first, this 
is a round in which there is no activity—so really it is the adversary who is both the first and the 
last agent to be active in a protocol execution. 


EXPOSED STATE. As we said, the exposed state is whatever information the adversary learns when 
corrupting a player. If a player ¢ is corrupted in adversary round r, his exposed state will always 
consist of all of the messages addressed to him in round r (which would have been delivered to him 
at the beginning of players’ round r+1), together with some information, E(H{), about his current 
view. Since we are now aiming at defining secure computation with respect to the most powerful 
natural adversary, through out this chapter we let the ezposed state function E be the identity. 
That is, by corrupting a player, the adversary gets, over the most recent messages addressed to 
him, the view of his execution of the protocol up to that point (thus, all prior messages, coin tosses, 
computational states etc.) 

The exposed-state function, as we shall see in the next discussion section, is essential in pin- 
ning down the underlying model of computation and communication, and different exposed state 
functions will be considered in later chapters. 


2.4.2 Formal description 


We now describe how an n-party protocol P executes in the presence of an adversary A. 


ADVERSARY CONFIGURATIONS. These should capture enough information to allow a convenient 
recursive formulation of how a protocol runs in the presence of an adversary, as player and adversary 
configurations progress from round to round and micro-round to micro-round. 


Definition 2.4 An adversary configuration (34, Ta, Ka) is an element of 


0,1}" x {0,1}? x gel. 
{0,1}° x {0,1} eae 


adversary’s future corrupted 
state coins players 


CONFIGURATION SEQUENCES. Let A be an adversary for an n-party protocol, and let P be 
such a protocol. We describe how, from a common input c, any n initial player configura- 
tions, (C?°,...,C2°), any initial adversary configuration, C9° = (34,ra,%a), and any exposed- 
state function E: {0,1}" — {0,1}°, protocol P and adversary A generate a sequences of player 
configurations, {Cj°: ¢ € [l..n],r € [0..2],0 € N}, and a sequence of adversary configurations, 
{C'7’:r € [0..R], p € N}. Sometimes, one or more of these configurations may fail to be defined by 
the recurrences below. If this happens, the protocol is said to have diverged. 
Fix the notation 


rp rp rp 

Cy® = (8), 77°) and 
an rp orp orp 

Cah = (84, 7H) Ka 
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for player and adversary configurations. 

Let 9;- denote the least number such that M(s?'") = round-done (if such a number exists), and 
let 4, denote the least number such that A/(s%*") = round-done (if such a number exists). For 
clarity, we sometimes omit designating the micro-round to indicate the final micro-round of the 
indicated player or adversary round. For example, we may write 37, CY, 84, «4, and C4, in place 
of 85%", Cy@", sPAr, wi P4r, and C74", respectively. 

As before, define C7? = C}° = C2? for p € [1..00) and i € [1..n]. The players’ configurations 
progress as before, 


(P(c, 87°), 77°), if N(s;°) = compute 
CHOY =F (aiParif, rigris ---) if N(si?) = flip-coin 


CY if N(s;") = round-done 


(sf?ra ME, r7%") ifr >0 
corte 


Cie" if r= 0 
the only difference being that the set of actual messages delivered to player i from round r, Mj, 
will be defined differently. The adversary’s sequence of configurations progresses as follows: 


(A(c, 877), 7, wa if V(s°?) = compute 


(sper, rarity: -+, 62) if (8%) = flip-coin 


Cr) 
(siPeot, rf, KP U{i}) if (3%?) = corrupt, 
Ge if N'(s"?) = round-done 
+1)0 rey oie. sorb Ke 
ck jor (s%e4 aM, rea : Kea ) 


where o7 is the exposed state of processor i in round r, and M‘,*’ are the intended messages sent 


by good players and intercepted by the adversary at the start of her round r+ 1. These strings, 
and Mf, are defined below. 


Mi = M{*---*#Mlemij«---#mi, “Actual round-r messages visible to i” 
where 
r M(st) ift ZK’, 
M; = { ne ) if : ce “Actual round-r broadcast from i” 
1\SA A 


“Actual round-r message from i to j” 


ae eee if ig ny 


3] m,;(3%) if i E KA 


The intended messages prepared by good players during round r are given by 


Mm M(s{) ifi¢ wy! “Intended round-r broadcast prepared 
; A otherwise by good player i” 

we = m;(sf) ifi¢ Ka “Intended round-r message for j pre- 
a > A otherwise pared by good player i” 
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(Messages other than Mf and mj, may be delivered to processor j in round r + 1 because of the 
action of the adversary.) The exposed state of processor i which A will get hold of if she corrupts 
him in round r is given by 


Sa a ifr=0 “The exposed state of processor i at 
Siazpemi,*---#m’ «E(H!) ifr >0 round r.” 


for some fixed function E. (The definition of Hf is unchanged: H{ = (c,h9,h},...,A7), where 


ht = (87°, sf!,...,9;").) Finally, the incoming messages to the adversary at the beginning of her 
round r are given by 


y 5 py ne : . : “Incoming messages to the adversary 
Mi, = Mia---eM em’ ees em eee em” eee am” 
a at 7a a nn at the start of her round r” 
where 
ad f4 r—1 
nt = mi, if 7 € Ky 
4 A otherwise 


We add the stipulation to the above definitions that Mf = mi, = Mj = mi, = A for r = 0. 


EXECUTING PROTOCOLS. An initial configuration of the network is identified by a tuple (Z,c, 7,r4) 
specifying the players’ private inputs 21,...,2, € {0,1}°, the common input c € {0, 1}", the players’ 
coins T,,...,% € {0,1}°, and the adversary’s coins r, € {0,1}™. For a given protocol P and 
adversary A, an initial configuration of the network determines an erecution of P in the presence 
of A: this is the sequence of configurations {C;’, C4’} generated by P and A when the initial 
configuration of party i is taken to be C?° = (z,{i, r;), the initial configuration of A is (K4, Ta, a), 
for x4 = 9, player i’s coins are r;, the adversary’s coins are r,, and the common input is c. 

The set of executions of P with common input c, private inputs 2),...,2n, and all possible 
coin sequences r;,...,7, and r4 becomes a probability space by endowing each execution with the 
measure induced by taking each bit of r, and each bit of each r; to be selected uniformly and 
independently. In the presence of an adversary, erecuting a protocol P with com. ‘on input c and 
private inputs z,,...,2Z, means sampling from this probability space. 


ADMISSIBLE ADVERSARIES. As we have said, all our protocols are admissible; thus no adversary 
can force a good player to compute forever by sending him messages in some tricky way. On the 
other hand, the adversary can gain nothing if she herself computes forever—except for messing 
up our recursions! We say that an adversary diverges if she goes through an infinite sequence 
of computational states, her next-action function never indicating round-done. An adversary A is 
admissible if for any common input, any initial adversary state, any set of messages received, and 
any set of exposed states learned, adversary A does not diverge. From now on, all adversaries are 
assumed to be admissible. Thus, when a protocol interacts with an adversary, it does not diverge. 


ADVERSARIES WITH BOUNDED CHARISMA. If an adversary corrupts all the players, then nothing 
can be said about their behavior in her presence. We thus favor less captivating adversaries. 


Definition 2.5 Let t € N and let A be an adversary for an R-round protocol. We say that A is a 
t-adversary if A corrupts at most t players: that is, |«®| < t in any execution of P with A. 


For our purposes, it is equally acceptable to strengthen the constraint above and demand that a 
t-adversary always corrupt exactly ¢ players. 
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2.4.3 Remarks 
2.5 Discussion 


THE EXPOSED STATE. As we said, the exposed state represents all the adversary learns when she 
corrupts a player. What should this be? Certainly the adversary is entitled to the player’s com- 
putational state in that instant; indeed, a player must keep this information around for continuing 
executing the protocol. Also, she is entitled to learn the player’s private input; indeed, we aim 
at precisely capturing the situation of an ideal function evaluation, and she gets this information 
in that scenario. Additionally, we let the adversary learn all the messages addressed to a player 
which were sent in the same round in which she corrupted him; indeed, when rounds are simulated 
in an asynchronous communication model, the adversary might be lucky and get these messages 
early enough to use this information in making her decisions in the current simulated round. Thus, 
seeking a strong enough model to capture any “real” underlying network, we assume the adversary 
is always lucky. 

Besides these three components, we let the exposed state, a’, also contain a piece, E(H/), of 
player 1’s view, Hj, at the end of round r. Since this specified portion of the player’s view may 
not be recoverable from his computational state, why give it to the adversary? As with “prompt” 
message delivery to the adversary, our reason stems from modeling reality robustly. To avoid being 
unduly specific, we have rightly chosen a formalism that is silent about the nature of players and 
adversaries. In reality, though, an adversary may be able to exploit the peculiarities of the agents 
that perform local computation. For instance, if players are people, it may not be so easy to 
instruct them to forget their past and resist interrogation! Alternatively, the way in which coins 
are flipped may allow the adversary to recover all past coin tosses once a player is corrupted. In no 
case, however, can the adversary learn more about a player, by corrupting him, than his view. The 
exposed-state function E thus constitutes a “knob” to control precisely what additional information 
can be derived by an “actual” adversary corrupting an “actual” player. 


CHOOSING THE EXPOSED STATE. Though our notion of secure computation is applicable for all 
exposed-state functions E, we suggest that FE, at the minimum, divulge the current-round view 
of a corrupted player. (This can be formalized by saying that E(H{) = h{*E'(H]) for some 
function E’.) We define the standard model to be the one in which E gives exactly the current- 
round view, E( Hs) = ht. We have two excellent reasons for favoring the standard model. 


e Independence from asynchrony models. Achieving security in the standard model ensures in 
an elegant way that the adversary cannot exploit any asynchrony present in the underlying 
real communication system. In fact, the standard model eliminates the burden of formalizing 
and choosing among infinitely many and often incomparable models for an asynchronous 
adversary.® It is because we let the adversary receive the current-round view of corrupted 
players that we can neatly alternate player and adversary rounds. 


® Without receiving the current-round view of a corrupted player, it may be beneficial for the adversary to corrupt a 
player in the middle of his round of computation, since computing, in practice, “decreases” information. For example, 
one may consider an adversary who can corrupt a chosen player ¢ at chosen micro-round p. (This capability, which is 
subsumed by the standard model, is undesirable since it is not model independent; in fact, it depends in a crucial way 
on how much computation can be performed within a micro-round.) Another model allows the adversary to corrupt 
players only at the end of their rounds, like we do, still granting her private inputs, current computational states, 
and messages intended for corrupted players in the current round, but nothing else (i.e., our model with E = A). As 
this model is incomparable with the one just mentioned, which is better to adopt? “Below” the standard model lie 
myriads of specialized and not-too-interesting models. 
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e Independence from communication mechanisms. If public-key cryptography is possible, then 
secure computation in the standard model is achievable not only in the rich type of networks 
we describe, but even in ones where communication is only possible via broadcasting, or only 
possible via separate communication lines between every pair of players, even if these lines 
can be monitored by the adversary, as discussed in section XX. In fact, it can be achieved 
in any “reasonable” communication mechanism — a statement necessarily part theorem and 
part thesis. Here, by “reasonable” we essentially mean that the adversary cannot disrupt 
the communication between two good players, a property without which there is no secure 
computation. 


For the reasons given above, and for concreteness, we assume the standard model, unless stated 
otherwise. 

Another noteworthy exposed-state function is the identity map, E(Hj]) = Hj, which defines the 
complete-history model. The importance of this model is not only due to the fact that it gives rise 
to the worst adversarial scenario, but also to the fact that security with respect to it is achievable 
under at least one communication mechanism —in fact, as explained in section YY, the one adopted 
in this paper. 
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3 Secure Protocols 


As we said in the introduction, we define a secure protocol for computing a function to be one that 
mimics an ideal evaluation, in all of its aspects, as closely as possible. Thus, in this section, we 
recall what an ideal evaluation is, establishing a convenient notation for the rest of our enterprise; 
we highlight its important aspects; we define the sense in which a protocol can imitate them; and, 
finally, we set just how close this imitation should be. This last point is both important and 
delicate. Demanding “perfect imitation” is both easier and counterproductive: for the notion of 
secure computation to be of any use, it must allow the existence of secure protocols, at least in some 
reasonable models of communication. 

The notion of secure computation is inherently complex, even disregarding —as we do in this 
chapter— computational complexity issues and other, complicating issues. We thus decided to 
break its presentation in smaller and more manageable pieces of some independent interest. Ac- 
cordingly, we provide separate definitions of both correctness and privacy, and then show how to 
properly interleave them to yield the notion of security. While we hope that this will improve the 
readability of our paper, we ask the reader to keep in mind that it is secure computation which 
is our real aim! Thus, while meaningful alternatives to our definitions of correctness (alone) and 
privacy (alone) can be found, we strongly believe that any satisfactory definition for what it means 
for a protocol, in the presence of a sufficiently powerful adversary, to closely mimic an ideal function 
evaluation, will be essentially similar to ours. 

We do, though, encourage further work if felt necessary, and thus do explicitly highlight what 
we found to be the key ingredients and concerns for putting together any meaningful definition of 
secure computation. 


3.1 Ideal Evaluation 


VECTOR NOTATION. As usual, we denote a vector by a letter topped with an arrow symbol, “~”. 
The same letter without the arrow but with a subscript denotes the indicated component. For 
example, if Z is a vector, z; is its i** component. An n-vector is a vector with n components. 

Fix n, and let T C [1..n]. Then we write T for [1..n]—T. If Z is an n-vector and T C [1..n], the 
tagged vector rr = {(i,2;): 1 € T}. (That is, zy keeps track of the indices as well as the values.) 
To each two n-vectors Z and Z’ and subset T C [1..n], we associate the “shuffled” vector zp U 27, 
which is the n-vector 7 where y, = 2; if i€ T and y; = x, otherwise. For f: ({0,1}")" — ({0,1}")” 
and T C {1,...,n}, fr(Z) is defined as fr(Z) = (f(Z))r, and f;(Z) is defined as f,(Z) = (f(Z)); 
—thus f iz (fis--+>Sn)- 


THE IDEAL SCENARIO. Let 7 € ({0,1}")" be a vector and f : ({0,1}")” — ({0, 1}")” be a function. 
Then the ideal evaluation of f(z) in the presence of an adversary proceeds as follows: 

(1) the adversary dynamically (one at a time) corrupts some set T C [1..n] of the players; 

(2) she then chooses some fake inputs, 27, for them; 

(3) each uncorrupted player i now receives f;(z U 27) (from a “trusted party,” one sometimes 
imagines), while the adversary receives fr(zz U zr); 

(4) finally, the adversary may dynamically corrupt some additional players. When she corrupts 
a player j, she learns (z;, f;(z7 Uzp)). 
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3.2 Correctness (without privacy) 


So far, we have discussed executing a protocol in purely syntactic terms. In fact, we never even 
discussed the possibility of protocols having an output! Since the ultimate goal of our protocols is 
to securely evaluate a function, the time has come to add a bit of semantics to our setting. 

In this section we put forward a definition of “correctness without privacy.” That is, we provide 
a way to “rationalize” the execution of some protocols and distinguish those whose “net result” 
consists of correctly computing, in a weak sense, a function f. 

The weakness of the proposed definition comes exactly from our wish to ignore “privacy” for 
now. In fact, we believe that any computation in the presence of an adversary, to be robust, needs 
also to be a private one. Since, however, we will define security as a strengthening of the following 
notion of weak computation, all the quantities and concepts introduced here will be relevant to our 
future effort. Among these concepts is that of awareness, which will be particularly crucial. 


3.2.1 Awareness and Correctness 


There are, of course, several ways in which correctness without privacy may be intended. Since we 
aim here at making a step towards defining secure computation, the one we want to capture corre- 
sponds to an ideal evaluation without privacy; namely, an ideal evaluation in which the adversary 
knows, in advance, the initial inputs of all players. 

First, without much trouble, we can enrich protocols with a new syntactic function: an output 
function, defined on the final computational state, 


o: {0,1}" > {0,1}°. 
_— ———_ 
round-R output 
state value 

Armed of this small syntactical change, we now discuss a few definitions of “correctness without 
privacy.” Fortunately, we have little use of formalization here, since all considered definitions will 
be rejected, except for the last one which will be greatly expanded in later subsections. To simplify 
things further, we shall here be content of considering solely the case in which, whenever n players 
—whose initial inputs are, respectively, z;,...,2,—- want to evaluate a function f = (f1,..., fn); 
the adversary always corrupts a fixed set T of them at the very beginning. This way T will represent 
the set of good players at any step of a protocol execution. 


ELEMENTARY CORRECTNESS. A protocol whose only guarantee is that, upon termination, each 
good player ¢ outputs f; evaluated at “some” inputs, does not capture the desired an ideal evaluation 
without privacy. In the latter one, in fact, “these inputs” are the same for all players; moreover, 
the ones corresponding to good players coincide with the initial ones. We thus move on to consider 
the following 


Informal Definition: A protocol computes a function f = (f,,..., fn) with elementary correctness 
if, at the end of each execution, there exist values z4, such that every good player i outputs 
fi(zy U 2p). 

With proper language changes, elementary correctness corresponds to the original correctness con- 
straint of [Ya82a], and to that of many other researchers as well. At a first glance, it may appear to 
be exactly what we want. In fact, in the execution of any protocol, nothing prevents the adversary 
from corrupting a set of players T at the very beginning, substituting their initial inputs with z7, 
and then letting them follow the protocol scrupulously. If the protocol is assumed to compute a 
function in any meaningful sense, we should expect in this unavoidable circumstance that each 
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good player t ought then to output f,(zUzz). Since any reasonable definition should not demand 
what cannot be obtained, elementary correctness appears totally adequate in modeling an ideal 
evaluation without privacy. 

Unfortunately, things are more subtle, and some other important aspect has not been properly 
captured. 


AWARENESS. The definition of elementary correctness only requires that, in each execution, there 
exists some values z7 such that the good players will each output his component of f evaluated 
at their initial inputs “shuffled in” with fake inputs z>. In an ideal evaluation without privacy, 
instead, not only the corresponding 27 values exist, but the adversary is aware of them, since she 
actually hands them to the trusted party. This awareness aspect is an integral part of the ideal 
scenario, that is, one that we demand to be captured. Why such insistence? At first glance this 
awareness may appear something purely “psychological” and extraneous to a purely mathematical 
setting. Quite to the contrary, it is instead full of technical consequences, not the least of which 
being the much desired and needed reductbility property of secure computation. At this point of the 
paper, however, we are not yet in a position of of elevating the level of our discussion and justify 
this key choice of ours, and thus take a more formalistic approach: 


Since the adversary is aware of which inputs she substitutes in an ideal evaluation, we 
demand that she be aware of them in a correct-without-privacy computation (and a 
secure computation), as well. 


Though there may be some latitude in the formalization of adversarial awareness, we strongly 
believe it to be a central concern for secure computation. We wish to describe our notion of security 
without initially entangling the reader in the subtleties arising from this formalization. Thus, for 
now, we adopt a simple but restrictive notion of awareness, leaving to subsequent sections both 
relaxing it and discussing it from a complexity point of view. 


We say that the adversary is aware of some quantity associated to the execution of 
the protocol if that quantity can be computed by evaluating a specified fun: ‘ion on the 
adversary traffic. 


The adversary traffic simply consists of all the messages she sends and receives via the corrupted 
processors, the exposed state of the processors she corrupts, and the common input. These are 
quantities immediately available to her, and thus it is easy for her, if she so wants, to evaluate a 
specified function on them, thus yielding a simple and natural notion of awareness. (Further illus- 
tration of the rationale behind this initial choice of awareness may be found in the next discussion 
subsection.) 

To incorporate awareness, the definition of correctness without privacy will make use of an 
adversary input function, AZ. This function may at first be defined as mapping the adversary’s 
final traffic to a “fake” input, 2, indicating the value which the adversary regards herself as having 
substituted into the collaborative computation. 

At a second thought, rather than defining AZ on the adversary’s final view, we define it on 
any intermediate adversary view as well, and enlarge its range to contain the distinguishing value 
not-yet—indicating that the adversary’s activity has not yet resulted in her entering any substituted 
values into the joint computation. This way, while executing a correct-without-privacy protocol, 
by evaluating AZ on her growing traffic, the adversary can —if she so wants— be aware not only 
of which values she has substituted, but also when this substitution has taken place—something 
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which is certainly present in an ideal evaluation, with or without privacy. We call this temporal 
awareness. 

To keep things meaningful, we require a certain “monotonicity” property from AZ: namely, if 
some intermediate adversary view takes on a value z+ # not-yet, it will keep on assuming the value 
ry on any subsequent view. (Else, the interpretation that the adversary knows when the input 
substitution occurred would fail to hold.) Moreover, when evaluated on the final adversary view, 
AT should take a value different from not-yet. (Else, the interpretation that the adversary does 
eventually enter some fake values into the ideal evaluation would fail to hold.) 

Finally, the “fake” input the adversary substitutes is not the only thing she is aware of in 
the ideal evaluation. She is also aware of the private outputs of the corrupted players. Thus our 
formalization of correctness-without-privacy will make use of an adversary output function, AO. It 
maps the final traffic to a tagged vector yz, indicating the output “attributable” to each corrupted 
player i € T. 

We are thus led to the following 


Informal Definition: A protocol awarely computes the function f if there exist awareness func- 
tions AI and AO such that, upon termination, each good player i outputs f,(z~ Uap), t7 = 
AT (adversary traffic), and (what the adversary “can compute as bad player outputs” =) AO(adversary 
traffic) = yr = fr(zp Usp). 


WEAK COMPUTATION. Have we finally captured correctness without privacy? Not yet: there a 
“mismatch.” In an ideal evaluation without privacy, the adversary could substitute the inputs 
of the corrupted players with a given set of fake values wi, and, after this, she is entitled to 
become aware of the values fr(w> Uz). Unfortunately, there is not yet any guarantee that, in an 
execution of a correct-without-privacy protocol for f, the adversary may become aware of the result 
of evaluating the good inputs shuffled with a different set of fake ones, even though she executes 
honestly on behalf of each corrupted player. That is, assume after corrupting the players in T at 
the very beginning, the adversary sends messages on their behalf as if they were honest and had 
wi as the set of their initial inputs. By doing so she generates some specific traffic, traffic, for 
herself. However, our formalization so far does not guarantee that ATZ(traffic) = wy. This does not 
affect the output of good players at all, since, whether or not AZ(traffic) = w, each good player 
g € T will output f, evaluated at the good inputs shuffled with w>.’ What can, instead, be said 
about the “output” of the adversary? Only that in the ideal scenario it will be y4 = fr(w U zz) 
while in the protocol scenario will be yf = fr(AZ(traffic) U zz). Since there is no guarantee, so 
far, that AZ(traffic) equals w’,, there is also no guarantee that y/ equals yf. This “mismatch” 
would result in the non-composability of correct-without-privacy protocols! This may not be too 
bad per se, since correctness without privacy is for us only an intermediate step, but the notion of 
security would be affected the same way. 

To prevent this mismatch, a correct protocol implicitly defines a local input function, I. This 
function, evaluated at the message traffic of an individual player, yields the input of that particular 
player into the joint computation. Naturally, it must be the case that for each good player, this 
evaluation yields his initial input. The output of a correct protocol, both for the good players and 
the adversary, is correctly correlated with these local inputs. Awareness is guaranteed by having 
the projection of Z onto the corrupted players coincides with the result of applying AZ. 


This is so because, to a player in T, the situation in which all players remained good and the ones in subset T 
happened to have wy as their set of initial inputs, and the situation in which the players in T were corrupted, were 
given wy as a set of fake inputs, but otherwise followed faithfully the protocol, are totally identical. Thus, given that 
in the first situation each good player g € T would output fr(wyUzz), the same will happen in the second situation. 
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Let us try to explain a bit. The adversary cannot compute the input that a good player 
contributes to the computation via the public function AZ, since she does not have all the messages 
necessary to evaluate it. On the other hand, by evaluating AZ on her traffic, she can be aware of the 
inputs of the corrupted players. It should be noticed that this latter requirement is not, in general, 
a trivial one! In fact, the input of a corrupted player is determined by evaluating Z on his local 
traffic. When dealing with a dynamic adversary, capable of corruptiong players in the middle of an 
execution, this traffic is composed of two parts: a “good sub-traffic” containing all the messages 
sent and received when the was good, and a “bad sub-traffic” containing all of his messages after 
corruption. The adversary certainly knows the second sub-traffic, but to compute what input a bad 
player has really entered the computation one needs either to also know the good sub-traffic, or to 
have some other quantity that suffices for her to be aware of her corrupted players’ inputs. In the 
setting considered in our first three sections, the adversary will explicitly have access to the good 
sub-traffic. (In fact, we are defining security with respect to an adversary with the biggest, natural 
advantage. Accordingly, upon corrupting a player, she obtains, as his exposed state, his full view; 
thus, in particular, his good sub-view.) In general, in less adversarial models, the protocol must 
guarantee adversarial awareness through the function AZ. The resulting notion of security is what 
we call weak computation. A synopsis of it is offered by the following 


Informal Definition: A protocol weakly computes the function f if, upon termination, each good 
player i outputs f;(r7 U zz), where z, = AT(adversary traffic), and the adversary “can compute 
as bad player outputs” yr = fr(z7 Utz), where yr = AO(adversary traffic). Bad player i’s 
“input contribution” depends on his local traffic (and if this traffic pattern arises while i is good, 
it specifies his initial input.) 


The next subsections of this section are devoted at properly formalizing this notion. 


3.2.2 View and traffic 


Using the notation developed in the last section, we associate to the execution of an R-round 
protocol with an adversary some important quantities: an individual player’s view, the adversary’s 
view,, an individual player’s traffic, and the adversary’s traffic. 


A PLAYER’S VIEW. A player’s view encodes “everything that happens to him”; We already defined 
this quantity, but let us recall the definition here. For i be a player, his round-r view is the string 
hr = (87°, s7',..., 97%"), his view through round-r is Hj -- (c, h?,h},..., Af), and his final view 
is HR. 


THE ADVERSARY’S VIEW. The adversary’s view encodes “everything that happens to the adver- 
sary”. More formally, her round-r view is the string hi = (s7,3%,...,34°4"), her view through 
round-r is H%, = (c,h9,h4,...,4%), and her final view is H%. 


PLAYER TRAFFIC. Player i’s traffic records all the messages into or out of player i—whether or 
not player i is corrupted. To define this, recall that Mf is the message broadcast by i at the end 
of round-r, and mf; is the message sent from i to j at the end of round-r. Then player i’s round-r 
traffic is the string 


= (My+«Mj«---*+Mi emi) ,amy,# ++ em? 


r r r 
mir 5, *M5q*-+-*M;,), 


his traffic through round-r is T7 = (c, ¢9,t!,...,t{), and player i’s traffic is T. 
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ADVERSARY TRAFFIC. The adversary traffic records all of the exchanges between the adversary 
and the uncorrupted players: everything the adversary “gets” from good players (the messages they 
broadcast, the messages they send to corrupted players, and the information the adversary learns 
when one of these good players is corrupted), together with the information that the adversary 
“gives” to good players (the messages the adversary broadcasts on behalf of corrupted players, and 
the messages the adversary sends out along private channels to uncorrupted players on behalf of 
corrupted players). To define the adversary’s traffic, recall (from Page 23) the quantity M;, for 
the incoming messages to the adversary at the beginning of her round-r. Similarly, we introduce a 
notation for the out-going messages from the adversary at the end of her round-r. It is 


“Round-r messages sent out by bad 


gt y 9 . os « a 
Mi, = Mfe---+M emt *- mie em me, players.” 
where 
uw = Mi(s,) if ie wy “Round-r messages prepared by cor- 
: A otherwise rupted players” 
ni. = mi;(8%) ifie x and 7 Z K3°4" “Round-r messages from bad players 
4 A otherwise to good players” 


We add in the proviso that Mr = mj, = A for r = 0. Now, consider a round-r in which some 
number m of players are corrupted, in sequence: 71,...,im. The round-r adversary traffic is the 
string 


th, = (M4, (i1,0%,)s-+ +s (ims O7,)) M4) 


containing the messages received by the adversary at the beginning of the round; the corruption 
requests, in order, and exposed state given to the adversary as a result of these requests; and the 
messages composed and sent out by the adversary at the end of her round of activity. The adversary 
traffic through round-r is T; = (c, t9,t4,...,t%), and the adversary traffic is TR. 


NoTaTIion. Fix a R-round, n-party protocol, P, and an adversary, A. Then for any initial config- 
uration (Z,c,7,r,) there is an induced execution of P with A, and, consequently, for any player i 
and round r, there is an associated pla.er 7 view through round r, player i traffic through round r, 
adversary view through round r, and adversary traffic through round r. These are denoted by 


HAP" (z,¢,F, 174), TA?" (Z,c,7,ra), HA?’ (z,c,7,r,), and TA?" (Z,c,7,r4). When A and P are 


understood, we omit them as superscripts. 


3.2.3 Adversary input and output 
Definition 3.1 An adversary input function for an R-round protocol is a map 


AI: {0,1} x {0,1}" + 20-71xf01F Uy {not-yet} 
—_—— —_—— a4 


common adversary _fake 
mapas traffic pute 


such that for any c € {0,1}° and any well-formed sequence of traffic values T?,...,T#, indicating 
corrupted players KC ---C «%, there is some r < R for which 


e AT(c,T{) = not-yet for all F < r; and, 
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e For some tagged vector zp, T = x, and AZ(c,T4) = x} for all7 >r. 


An adversary output function for an R-round protocol is a map 


AO: {0,1}" x {0,1} > Ql -nlxfo.1}! 
{0,1}" x {0,1} 


common final deserved 
input traffic output 
such that for any c € {0,1}° and any well-formed sequence of traffic values T9,...,T%, indicating 


corrupted players Kk C---C wR, 
e For some tagged vector z-, T = «® and AO(c,T®) = z+ 


NOTATION. If P is an n-party, R-round protocol and A is an adversary, then any initial configura- 
tion (Z,c, ,r4) determines an execution of P with A, and hence a final adversary traffic T? and 
an adversary committal AI“? (z, c, 7, ra) AZ(c, T®). When A and P are understood, we omit 
them as superscripts. 

Similarly, protocol P, adversary A, and initial configuration (Z,c, 7,r4) determine an adver- 
sary output AO*?(z,c, 7, raJZAT(c, T®), When A and P are understood, we omit them as 
superscripts. 


3.2.4 Network input and output 


NETWORK INPUT. Fixa protocol P and an adversary A. It is natural toextend AZ(Z,c, 7,r,) toan 
n-vector by including, along with the substituted inputs of corrupted processors, the original inputs 
of the processors which were uncorrupted at the time that AZ specified a substituted value. Thus 
we define the network input, AT(z, c, 7,7), as 2 Ur, where z> = AT(Z,c, 7,r,). Intuitively, 
the network input is the good players’ original inputs “shuffled in” with the substituted inputs 
the adversary regards herself as entering into the collaborative computation; it specifies, for the 
indicated execution, what the network has entered into the joint computation on this run. 


NETWORK OUTPUT. Fix a protocol P and an adversary A. It is natural to extend AO(Z,c, 7,74) 
to an n-vector by including, along with the adversarially-perceived outputs of corrupted players, 
the private output of the players which were uncorrupted at the protocol’s conclusion. Thus we 
define the network output, A(z, c, T,T4), a8 yy U yp, where yy = AO(Z,c, r,7r4) and yp is 
defined by y; = o(s*), for i € T. Intuitively, the network output consists of the good players’ 
outputs “shuffled in” with the outputs the adversary regards herself as having been given as a 
result of the collaborative computation; it specifies, for the indicated execution, what the good 
players did compute as output values, and what the adversary could compute on behalf of the 
corrupted players. 


3.2.5 Local input 


DEFINITION OF A LOCAL INPUT. Local input functions for protocols have a bit too much structure 
to conveniently define them in one swoop. So we break the definition in two; first, as a syntactic 
object: 


Definition 3.2 A local input function is a map 
I: [ln] x {0,1}* x {0,1} + {0,1} U {not-yet} 
—— ne a nee Nomen ore 
player common player's committed 


input traffic input 
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We denote Z(i,c,T) by Z;(c,T). 

Now fix an n-party, R-round protocol, P, and a t-adversary, A. Any initial configuration 
(Z,c, 7,r,) determines an execution, and hence a collection of player traffic values, {T7: i € 
[1..n],r € [0..R]}, and a collection of players corrupted during this execution, {x’,}. We define the 
following quantities associated with the specified execution: 


e (The round-r input of player i.) Tf (Z,c, F,ra) = I,(c,T7) 

e (The round-r input of the network.) I"(Z,c, 7,r4) = (Zi(c,T7),.--,Zn(e,T%)) 
e (The committed input of player i.) I;(Z,c, F,r4) = I7(c,T7) 

e (The local inputs.) I(Z,c, F,r4) = (Z,(c,T#),...,In(c, T*)) 

e (The bad players at round-r.) Bad" (Z,c, 7,r4) = K% 

e (The good players at round-r.) Good" (Z,c, 7,r4) =([l..n] — Ky 


For Z to be a local input function that is “ok” with respect to a protocol P, we need the following 
additional structure: 


Definition 3.3 Fix t € N and a R-round, n-party protocol, P. We say that an T is a t-local input 
function for P if for every t-adversary A the following conditions hold: 


e (Monotone committal.) T7(Z,c, 7,r4) = 2; € {0, 1} => Tjt'(Z,c, Fra) = 2; 

e (Simultaneous committal.) Tj (Z,c, 7,74) = not-yet => Tf (Z,c, 7,74) = not-yet 
e (Eventual committal.) T,(Z,c, 7,74) € {0, 1} 

e (Meaningful committal.) g € Good’ (Z,c, 7,74) => Ij (Z,c, 7,74) € {not-yet, z;} 


ADMISSIBLE ADVERSARY INPUT FUNCTION. An adversary input function is admissible if it coincides 
with a local input function. More formally, 


Definition 3.4 Fix an n-party, R-round protocol, P. An adversary input function for P is t- 
admissible if there exists a t-local input function Z for P such that for any t-adversary A and initial 
configuration (Z,c, 7,74), any round r and player i € Bad"(7Z,c, 7,r4), 


e ATZ(c,T4) = not-yet > Z(c,T;) = not-yet, and 
e AZ(c,T4) = 27 > T(c,T;) = xj for allie T, 
where Tf = Tj (Z,c, 7,74) and T, = T4(Z,c, 7,14). 
3.2.6 Weak correctness 
We now describe what it means for a protocol to weakly compute a finite function. 


Definition 3.5 Let n,¢,1,t €N, let f: ({0,1}‘)" — ({0, 1}')" be a function, and let P be a fixed- 
round, n-party protocol. We say that P perfectly t-weakly computes f if there is a t-admissible ad- 
versary input function AT and an adversary output function AO such that for every t-adversary A, 


AQ(Z,c, 7,14) = f(AL(Z,c, 7,r4)). 
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3.2.7 Remarks 


EXISTENCE OF WEAKLY CORRECT PROTOCOLS. 


TRAFFIC vs. VIEW. In subsequent sections, we both relax our notion of awareness and discuss 
its complexity. We wish, however, to briefly discuss here the rationale for letting it depend on the 
traffic. Let’s concentrate on adversarial awareness, since similar points can be made on player’s 
awareness. Why not, for instance, allow adversarial awareness to arbitrary depend on the full 
adversary view? (Here, by adversary view we mean the adversary traffic plus all the coins she 
has tossed; alternatively, it is the sequence of her computational states.) There are at least two 
excellent answers. 


e On the philosophical side, this view is meant to capture all that affected her computation, 
not necessarily what she is aware of. For instance, the adversary might have a source of en- 
tropy for randomizing her state, without having explicit access to her underlying coin tosses. 
More generally, if the adversary is a person, it may be unrealistic to say that she knows a 
full description of her own state, so as to be able to evaluate a function on it. By defining 
adversarial awareness as a function of her view, we would be making an unnecessary assump- 
tion about the nature of an adversary, and we would ultimately obtain a notion of security 
adequate only if the adversary is —say— a Turing machine. It is, instead, incontrovertible 
that the adversary, independently of her nature, has immediate access to (and thus is aware 
of) her traffic. Thus, ignoring complexity concerns, computability on the traffic is a simple 
and natural notion of awareness. 


e A more technical answer is that adopting too generous a notion of awareness (like computabil- 
ity on the adversary’s full view) seems to entail, at a very close examination, loosing crucial 
properties of secure computation—such as reducibility. 


Thus, while for some agents, awareness can depend on additional quantities, both weak-computation 
and secure protocols make sure that it only depends on the traffic. This way, they guarantee the 
independence of their respective notions from the nature of the particular agents. 


3.3. Privacy (without correctness) 
3.3.1 Motivation 


A secure computation of a function f should mimic—as closely as possible—its ideal evaluation; 
that is, roughly, it should be exactly as private and exactly as correct. Though we will ultimately 
insist that these two issues be handled together in a protocol we call secure, privacy by itself is 
meaningful and interesting notion. In this section, we describe a notion of “privacy leaking f,” 
motivated by the ideal evaluation. 

Privacy is a measure of how much the adversary learns. Of course, in any protocol correctly 
computing f the adversary can learn at least the ideal information—the information available in the 
ideal evaluation. (In fact, she can dynamically corrupt a few players during her round 0 using the 
same strategy she would use in the ideal evaluation; give them the same fake inputs she would give 
them in the ideal scenario; then let them run as in the original protocol; then corrupt, during her 
final round, additional players, as she would in the ideal evaluation. This way, upon termination, 
the adversary will learn all the information available to her in the ideal evaluation.) In any correct 
protocol, however, the adversary sees additional information: the adversary traffic generated by the 
protocol and, more generally, her own view. Thus a secure protocol for evaluating f should ensure 
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that this view does not contain more than the ideal information. In fact, we want it to contain 
precisely the ideal information. We express that a secure protocol is exactly as private as an ideal 
protocol by saying that: 


(i) (THE PROTOCOL IS AT LEAST AS PRIVATE AS THE IDEAL PROTOCOL.) There must 
ezist an agent which, knowing only the ideal information, manages to interact with the 
adversary so as to generate for her what is essentially the same view as she gets when 
interacting with the real network of players. 


(ii) (THE PROTOCOL IS AT MOST AS PRIVATE AS THE IDEAL PROTOCOL.) From the 
information obtained in executing a protocol, the adversary should be able to “extract” 
the ideal information. 


The principal tools for properly expressing the above ideas are simulators and awareness. The later 
we have already seen, while the former is the agent that generates the right view for the adversary. 
It does this with the aid of an tdeal-evaluation oracle, an abstraction which models possession of 
the ideal information. 

Once we have in hand a notion of how an adversary interacts with a simulator, the notion of 
privacy is close at hand: all we have to say is the the adversary—network interactions are “just like” 
the adversary—player interaction. The crux, of course, is in saying what “just like” means—but 
this task is made easy for us by now well-known notions in modern cryptography. 


3.3.2 Ideal-evaluation oracles 


An ideal-evaluation oracle is a special, history-dependent oracle. For any n-vector Z and function 
f : ({0,1}")” — ({0, 1}")", the ideal-evaluation oracle O,(Z) responds to two types of queries: 


e A component query is an integer i € [1..n]. How a component query is answered depends on 
whether or not a valid function query has been made. If a valid function query has not yet 
been made, then the component query i is answered by z;. If a valid function query z7 has 
been made and ¥ = f(z} Uz), then component query ¢ is answered by (z;, y;). An invalid 
component query is answered by the empty string. 


e A function query is a tagged vector z. A function query z> is valid if it is the first query 
of this type and T consists precisely of the compon 1t queries made so far. If z> is a valid 
function query and y = f(z7 U zy), then the function query is answered by yr. An invalid 
function query is answered by the empty string. 


Clearly, if Z represents the players’ private inputs and f is the function that they want to collabo- 
ratively compute, then having an 0,(@) oracle precisely captures possessing the ideal information: 
what an adversary can learn in the ideal evaluation of f(z) by corrupting t players she can also 
learn by making t component to an O;(Z) oracle, and vice versa. 


3.3.3. Simulators 


As suggested by Figure 2, an adversary interacts with a simulator with “mechanics” similar to 
her interacting with a network. (In fact, the interesting simulators are those which cause these 
interactions to be indistinguishable to the adversary.) For example, since an adversary expects to 
see messages broadcast by uncorrupted players, a simulator is equipped to provide such messages; 
since the adversary can corrupt a player and learn his exposed state, a simulator is equipped to 
specify it. 
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Figure 2: A simulator S creates a “virtual world” and allows the adversary A to act in this world, as 
though S itself were a network, N. To accomplish this, a simulator is provided an ideal-evaluation 
oracle O,(Z). Above, r4 are the adversary’s coins, and rs are the simulator’s coins. 


To meaningfully interact with an adversary, a simulator has access to an ideal-evaluation or- 
acle, O,(Z). It is crucial that the simulator’s access to this oracle and its interaction with the 
adversary be properly coordinated—else, one does not obtain a meaningful notion of security. We 
specify this coordination below: 


e When, and only when, the adversary A with whom the simulator S interacts corrupts a 
player i, the simulator makes a component query of i. 


e The strategy employed by the simulator to come up with its function query consists of eval- 
uating an adversary input function, AT. 


e The simulator makes this function query immediately following the completion of an adversary 
round. 


Let us briefly justify these choices. The first requirement highlights that it would be unacceptable 
if an adversary could, say, corrupt players 1, 3 and 4, and the simulator, in response, would ask 
the private inputs of players 2, 3 and 7; were this allowed even simple serial composition properties 
would not hold for the resulting notion of privacy. The second constraint is at the heart of our 
blending of privacy and correctness; it guarantees that in a computation with the network, the 
adversary is forced to “know” the value x7, that she has effective entered into the joint computation. 
This same value will be used to define correctness. The last assumption concretizes the intuition 
that the adversary can enter a value z> into the collaborative computation only by sending out 
messages, not by corrupting some player. 


History. Before proceeding further, we would like to mention, at least briefly, a history of the 
ideas of this subsection. The notion of using a simulator for proving and, more importantly, for 
defining that the amount of knowledge learned in an interaction is bounded, is due to Goldwasser, 
Micali and Rackoff [GMR89]. Our notion of a simulator, however, is, by necessity, more demanding 
than the one developed in their context. In particular, while our simulator must interact with an 
adversary in a manner similar to an adversary interacting with a network—implicitly assembling a 
transcript associated to this interaction which is precisely the adversary’s view—simulators in the 
sense of [GMR89] may lay down an arbitrary transcript intended to resemble the adversary view. 
Thus we distinguish our simulators as being “on-line.” 
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In fact, on-line simulatability was already recognized as possessing a useful structure. Kil- 
ian [Ki89] discusses interactions of this form, and they are explicitly required in the work of Crépeau 
and Micali [Cr90}. 

We note that on-line simulatability is essentially unrelated to the notion of black-box simulata- 
bility, an idea first investigated by Oren {Or87]. Black-box simulatability concerns the manner in 
which a simulator may depend on the adversary it is intended to simulate, while on-line simulata- 
bility concerns the mechanism in which “simulated” adversary transcripts are assembled. (In fact, 
we have not yet discussed the extent to which our simulators may depend on the adversary with 
whom they speak.) 


3.3.4 Formal description 


We now define what a simulator is and how it runs with an adversary A, using a particular oracle 
O,(£) and adversary input function AT. 

Let us briefly explain why a simulator, as an agent, looks different from players and adversaries. 
In describing protocols and adversaries, we insisted on a fine level of granularity. This was necessary 
because, for a player, any single chunk of probabilistic computation significantly alters his internal 
state of knowledge, and may make it more profitable or less profitable to corrupt him; for the 
adversary, we needed to pin-point her ability to corrupt several players in sequence within a round, 
and to specify exactly the view she gets in the execution of a protocol. On the other hand, for a 
simulator it is important to tightly coordinate its interaction with the oracle and the adversary, 
as we have already specified, but capturing precisely the simulator’s internal state at each point 
in time is less crucial. Thus for a simulator we can get by with a “coarser” level of granularity. 
In fact, we do not keep track of its individual coin tosses: a simulator moves from computational 
state to computational state in complete knowledge of its infinite sequence of coins. Since these 
coin tosses remain fixed (i.e., are never explicitly “stripped off” as they were with the players and 
the adversary), a simulator’s configuration may be regarded as coinciding with its computational 
state. 

Though one would do, we associate to a simulator two syntactic function, o and yp. When applied 
to the simulator’s computational state “at the right time,” these specify what the simulator sends to 
the adversary. Specifically, when the adversary corrupts a player 7, she expects her computational 
state to be augmented by the exposed state of of the newly corrupted player. Imitating this, 
the simulator evaluates o on its computational state and the result of this is appended to the 
adversary’s computational state. Likewise, at the beginning of an adversary round, the adversary 
expects to have her incoming messages M’, augment her computational state. Imitating this, the 
simulator evaluates ys on its computational state and the result of this is appended to the adversary’s 
computational state. 


Definition 3.6 A simulator S is a function 


S: {0,1} x {0,1}" x {0,1} > {0,1}". 


common current simulator new 
input state coins state 


A simulator syntactic function is either of the following functions: 


e a simulated exposed state function a: {0,1}" > {0,1} 
ee — 


current simulated 
state exposed state 
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e a simulated incoming-messages function 4: {0,1}" > {0,1}° 
—— — 
current simulated 
state incoming messages 


Discussion. As before, the simulator syntactic functions are fixed maps, each determining its range 
point in a natural, easily encoded manner from its domain points. As usual, we omit specifying 
these functions. 


CONFIGURATION SEQUENCES. Let f: ({0,1}‘)" — ({0,1}‘)" be a finite function, let A be an 
adversary for an #-round, n-party protocol, and let AZ be an adversary input function. If S is a 
simulator then running adversary A with simulator S, oracle 2,(Z), adversary input AZ, common 
input c, initial adversary state 4, adversary coins rq, initial simulator state 35, simulator coins rs, 
and initial corruptions x4, is a way to map the initial adversary configuration, C9° = (s4,r4,a); 
to a final adversary configuration, C2 = CRe*. 

To describe this mapping, fix the notation that C5’ = s%”, let 04, be as before, and let the 
adversary configurations progress according to the following recurrences: 


(A(c, 872), 737, KP if N'(s%?) = compute 
ats (sy #r di, Tatas +) Ka) if M(s7) = flip-coin 
cy’ 
(sfra(ss?"), rf, wf U {i}) if M'(s%) = corrupt, 
Ce if (3?) = round-done 
Cra = (s7f4r au(s9t), rifar qi ear) 


while the simulator’s computational state progresses according to 


S(c, sy #0" (7), rs) if N (3%?) = corrupt; 
ser) = 


sy otherwise 


(r+1)0 
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S(e, 86°47 40(AT(c, T4)) 
where, to specify the behavior of the oracle, we set 
z; if AT(c,T4) = not-yet 
tt) 


(ti, yx) if AZ(c,T{) = zp and 
7 = f(z_ U tp) 
Q(2z7) = yr where f= f(z7 Uz) 


and Q(not-yet) = A. As usual, 7% denotes the traffic to the adversary through round r. 


EXECUTING AN ADVERSARY WITH A SIMULATOR. Consider a fixed-round protocol, P, having 
adversary input function AZ. An ezecution of an adversary A with a simulator S, ideal-evaluation 
oracle 2,(Z), adversary input function AZ, common input c, adversary coins r,, simulator coins rs, 
and initial corruptions «4 = 0, is the collection of configurations {C%4’, 34°} generated, as above, 
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when the initial computational state of the simulator is cxx, and the initial computational state 
of the adversary is K,. 


ReMaARK. The fact that the simulator computes its function query by evaluating an awareness 
function imposes a restriction on the way the simulator computes the function query. The awareness 
property not withstanding, the function query might also depend on the coin tosses of the simulator, 
which are not part of the adversary traffic. By binding together the function query and the adversary 
input function AZ, we intertwine privacy and awareness in a significant way. 

The AO function, instead, poses no restrictions on the simulating algorithm. However, suppose 
that the adversary A has oracle 2;(Z) and the adversary and simulator S interact leading to an R- 
round traffic T®. In this interaction, suppose the simulator asked a function query 2’, as indicated 
by AT, and the players of set TJ were corrupted at termination. Then, in light of (ii) on Page 35, 
one would expect that 

AO(TR) = fr(2'p U zz). 


In fact, we might have demanded this relationship between 5, AZ, and AO (for any adversary A), 
dismissing most uninteresting cases. But it is not necessary to do so; the assertion above will be 
true automatically (except perhaps a negligible fraction of the time) in a protocol we call “secure.” 


3.3.5 Ensembles 


Ensembles are collections of probability measures; they provide a convenient abstraction for dis- 
cussing asymptotics in many cryptographic scenarios. Our ensembles bear two indices, which are 
treated differently. Since one of these will always be a security parameter, we being by giving some 
intuition on what one is. 


SECURITY PARAMETER. Very informally, a computation achieves perfect security if its execution 
imparts to an adversary absolutely no information beyond what is divulged in the corresponding 
ideal computation. 

Unfortunately, for most reasonable cryptographic scenarios and for most interesting tasks, the 
goal of achieving perfect security is not obtainable. Thus we must be less demanding, allowing our 
protocols to fall short of perfect security in a well-specified, quantizable way. A security parameter 
is used to measure how far a protocol is from the ideal scenario. The larger its value, the more 
secure the resulting executions, and the closer to the abstraction one is achieving. Before they run 
a protocol, players agree to use an adequately large security parameter to satisfy their needs. 

Since our notion of a secure computation allows “imperfect” security, it explicitly depends on 
a security parameter, k. We establish the convention that this security parameter is presented to 
the players and the adversary on the common input, written in unary. In fact, for now we fix the 
convention that the common input c contains only the security parameter: c = 1*. 


DEFINITION OF AN ENSEMBLE Our notion of an ensemble is somewhat more general than that 
of [GM84]. We define it below. 


Definition 3.7 If £ = {L, C {0,1}°: & € N} is a family of languages, then an ensemble E (over £) 
is a collection of probability measures on {0,1}", one for each (k,w) € N x Ly. The argument k is 
called the index of the ensemble E, the argument w is called the parameter of E, and CL is called the 
parameter set of E. 


As the index k is always drawn from N, we never specify it, writing E = {E,(w): w € Ly} to 
indicate an ensemble over C = {L,}. When the parameter set of an ensemble is understood and 
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there is no danger of confusion, we refer to an ensemble by writing the symbol “£” in front of its 
“generic element”—that is, we simply write €E,(w) instead of {E,(w): w € Ly}. 


The above notion of an ensemble applies only to distributions on strings. However, the notion 
is trivially extended to any other domain whose elements can be canonically encoded as strings. 
We will thus speak of ensembles on other domains, where it is understood that there is, implicitly, 
a fixed encoding of domain points into strings. 


AN EXAMPLE OF AN ENSEMBLE. A probabilistic encryption algorithm is an algorithm E that takes 
as input a security parameter, k, a message, m, and a sequence of random coins, r, and produces as 
output a cyphertezt, y, which is an encryption of m. The algorithm E produces its output in time 
polynomial in the security parameter. Thus a probabilistic encryption algorithm can only encrypt 
messages m whose length is bounded by some polynomial, Ri, i in the security parameter. 

Fixing the security parameter, k, a message m € {0, 1}"', and taking each bit of the random 
coins r to be selected uniformly at random, the algorithm E idaeed a distribution E,(m) on space 
of encryptions of m under security parameter k. Letting C = {L, = {0, 1}**}, these distributions 
form an ensemble € E,(m) over CL. 


ENSEMBLES FOR SECURE FUNCTION EVALUATION In defining secure computation, two ensembles 
will be of importance to us. One is the ensemble of views the adversary sees when she interacts with 
the network, while the other is the ensemble of views she sees when interacting with the simulator. 


The ensemble induced by a network. Consider an adversary, A, interacting with a network running 
an R-round, n-party protocol, P. When z € ({0, 1}‘)” is the vector of player inputs and the security 
parameter is k, so c = 1*, then for each pair (7,74) of player random strings and adversary random 
strings there is an associated adversary view. If 7 and r,4 are allowed to vary, then there is an 
induced distribution on these adversary views, which we denote by A-VIEW/ (2). If and k are 
allowed to vary as well, we obtain an ensemble 


€£A-VIEW{ (#) 
over L = {L, = ({0, 1}‘)"}. 


The ensemble induced by a simulator. Let f: ({0,1}‘)" — ({0, 1}')", and consider an adversary, A, 
interacting with a simulator § = (S,AZ) for an R-rouud protocol. When Zz € ({0, 1}‘)", the 
security parameter is k, and the simulator 5 equipped with an O,(Z)-oracle, then for each pair 
(ra,rs) of adversary and simulator random strings there is an associated adversary view. If ra 
and rs are allowed to vary, then there is an induced distribution on these adversary views, which 
we denote by A-VIEW$" (2). If Z and k are allowed to vary as well, we obtain an ensemble 


£A-VIEW #47 (2) 
over L = {Ly = ({0,1}‘)"}. 


3.3.6 Indistinguishability 


A central notion in this paper is indistinguishability, as introduced by [GM84] in the context of 
encryption. (The notion has also proven crucial for a complexity-theoretic treatment of pseudoran- 
dom generation [Ya82b] and of zero-knowledge proofs [GMR89].) Essentially, it captures the idea 
that two families of distributions can be (asymptotically) so close as to be considered the same. To 
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say this exactly requires some specialized language—the notion of a distinguisher and a probability 
ensemble. The reader who wishes a bit more discussion of these notions may consult [GMR89] 
(pages 191-193). 


NEGLIGIBILITY. We will say that a function «: N > R is negligible if it is nonnegative and vanishes 
faster than the inverse of any polynomial: for any c > 0 there exists a K € N such that e(k) < k~° 
for all k > K. A function e(k) which is not negligible is called nonnegligible. 


DEFINITION OF INDISTINGUISHABILITY. We now specify what it means for two ensembles to be so 
close as to be considered insignificantly different. 


Definition 3.8 Ensembles E and E’ are statistically indistinguishable, written E ~ E’, if they are 
over the same parameter set L = {L,}, and 


e(k) = sup > |Probs, («){2] - Probe; 4){2]| 
weLr r€{0,1}* 
is negligible. 
When we wish to emphasize the parameter set C of indistinguishable ensembles E and E’ we write 
E~x E’. 
£ 
3.3.7 Privacy 
We give a rather stringent definition of privacy below. 
Definition 3.9 Let n,é,1,t € N, let f: ({0,1}')" > ({0,1}')* be a function, and let P be a fixed- 


round, n-party protocol. We say that P is statistically t-private leaking f if there is a simulator S,, 
and an adversary input function input function AT, such that for any t-adversary A, 


EA-VIEW{ (Zz) x €A-VIEW}'“7 4 (2). 


3.3.8 Remarks 


ABSOLUTE PRIVACY. A special case oi a private protocol leaking f is an absolutely private protocol: 
such a protocol is one which is private leaking “absolutely nothing”—the constant map f = A, say. 
Privacy alone, and absolute privacy in particular, are useful notions; for instance, the COMMIT 
protocol of a verifiable secret sharing should be absolutely private. (See [CGMA85] for introducing 
the notion of a verifiable secret sharing, [FM90] for a protocol and crisp definition, and [RB89] for 
another important protocol.) 


Vi vs. Vv. 


3.4 Security (without history) 


As we shall see, a secure protocol is somewhat more than one which meets the previously given 
privacy and correctness constraints. In this section, we define our most basic definition of security. 
Since it ignores the possible “history” of players and the adversary the notion is called “security 
from scratch.” 
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3.4.1 Security from scratch 


We define what it means for a protocol P to securely evaluate a finite function f, from scratch, 
ignoring issues of computational complexity. 


Definition 3.10 Let n,¢,1,t © N, let f: ({0,1}‘)" — ({0, 1}')” be a function, and let P be a fixed- 
round, n-party protocol. We say that P statistically t-securely computes f from scratch, ignoring 
complexity, if there is a simulator S$, a t-admissible adversary input function AZ, and an adversary 
output function AO, such that for any t-adversary A, 


e Privacy: (The adversary’s view when she talks to the network is indistinguishable from her 
view when she talks to the simulator.) 


EA-VIEW? (2) % EA-VIEWS47 4 (2). 


e CORRECTNESS: (The network output almost always coincides with f evaluated at the network 
input.) There is a negligible function e(k) such that for all Z € ({0, 1}‘)", 


Prob [AO(z, 1*, Fra) # f(AT(E, 1, 7, r4))| < «(k), 
where the probability is taken over all possible 7 and r,. 


The privacy constraint asserts indistinguishability of ensembles over L = {Ly = ({0,1}‘)"}. The 
correctness constraint says that almost never does a good player i compute something other than 
f(z"), or a bad player j not “know” f;(Z’), where Z’ is the network input. 


3.4.2) Remarks 


EXPLANATION. Definition 3.10 can be explained as follows. For this explanation, we regard sim- 
ulation as a game the adversary plays “in her head,” the purpose of which is to construct some 
view. 


e Privacy. When the adversary talks to the network, the players’ inputs being 7, what she sees 
is something which she can generate for herself, given just an ideal-evaluation oracle, ,(Z). 
In fact, with the aid of such an oracle, the adversary can simulate, in her subconscious, a 
virtual network, interacting with which is just like interacting with the actual network. 


e Correctness. When the adversary interacts with this virtual network, on each execution she 
must make an output query to the oracle. What this output query is, and when she makes 
it, is determined by a function AZ. Now, if the adversary speaks to an actual network in lieu 
of the virtual network, the same function AZ still indicates what the “output query is”, and 
“when it would be made.” Of course, there is really no output query being made—but we 
take the value of AZ as defining what the adversary has committed to, and when. 
Correctness says that if the adversary has committed to a value z7, and the initial input 
was Z, then, almost certainly, each good player i will compute f;(z7 Uz). Additionally, 
the adversary can compute a value f;(z7 U zz) on behalf of any bad player j. She does this 
simply by evaluating the adversary output function, AO. 
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ADVERSARIAL AWARENESS. We emphasize that not only is there a notion of what the adversary 
has substituted in for the input values of the bad players, and when she has done it, but, what 
is more, the adversary is aware of what this substituted value is, and when this substitution took 
place. This is called input awareness. One could, instead, have defined the adversary’s input in a 
way which did not require such awareness—but doing this would represent a failure to mimic an 
important aspect of the ideal evaluation. 

Besides input awareness, the adversary is aware of her share of the output—the output which 
bad players are entitled to, even though they are bad. This is called output awareness. 

Adversarial awareness—meaning both input awareness and output awareness—are essential 
ingredients in obtaining the reductbility result discussed in Section 5.5. 


WHY ON-LINE SIMULATABILITY? 


BLENDING PRIVACY AND CORRECTNESS. We might have made separate definitions of privacy and 
correctness, and then said that a secure protocol is one simultaneously meeting both of them. 
Instead of this, our definition blends privacy and correctness in a deeper manner. Given that this 
is done implicitly in Definition 3.10 we explicitly say it here: the simulator—crucial in defining 
privacy—specifies the adversary input function, AZ, and therefore the network input function it 
determines, AZ. The correctness constraint depends on this network input, and thus on the notion 
of privacy and the simulator which establishes it. In this way, we “weave” correctness into privacy, 
the same simulator used for defining privacy being used to define correctness, too. 


DECOUPLED PRIVACY AND CORRECTNESS. Since our method of blending of privacy and correctness 
is a somewhat delicate admixture of these objectives, it is important to explain what is wrong with 
decoupled security—saying that a secure protocol is one simultaneously meeting disjoint require- 
ments for privacy and correctness. In fact, decoupled security can lead to various “embarrassing” 
problems can result! Let us be more concrete, even if somewhat informal. 

For concreteness, when we say “privacy alone” we mean the notion of t-private leaking f, as given 
by Definition 3.9; and when we say “correctness alone” we mean the notion of t weakly computing f, 
as given by Definition de-weakcorrecntess. Pleasantly, however, our criticism of decoupled notions 
of security is immune to variants in definitional choices for privacy and correctnes- We emphasize, 
for decoupled security, the function AZ© used for correctness need not be linked or related in any 
manner to the function AZ? used for privacy. 


Decoupled security. What is wrong with decoupled security? An example from our work with 
Kilian is useful for answering this question [KMR90]. 

Suppose there are three players, each player i having a private input 2, € {0, 1}. Let z,{1:£-1] 
denote z; stripped of its last bit. Consider the following function f that the players may wish to 
jointly compute. For each 1 € {1,2,3}, define 


fieveen= z,[1:€-1] if the last bit of zz is a 0, and 
Merde wae © 3)" ) 2a[1:¢— 1] if the last bit of z2 is a 1. 
That is, each player is to learn the same string, either the private input of the first player or second 


player, as determined by the parity of the second player’s input. 
Consider the following protocol, P,. 


PROTOCOL P,: 


Step 1. Player 1 announces his input, 2. 
Step 2. Player 2 announces his output, y2. 
Players 1 and 3 take y, this as their output, too. 
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We claim that protocol P, is 1-private leaking f. Very roughly, the argument is as follows. The 
main concern is about Player 2; for simplicity, consider the case that the adversary corrupts him 
tight off. Now privacy requires the existence of a simulator § = (S,AZ). But if we define the 
adversary input function as being identically 0, then the adversary learns x, right away from its 
ideal-evaluation oracle. Using this value, the simulator can easily interact with the adversary so as 
to give to her a view from the right distribution. 

Likewise, protocol P, 1-weakly computes f. Very roughly, the argument is as follows. The main 
concern is about Player 2; for simplicity, consider the case that the adversary corrupts him right 
off. If we define the adversary input as consisting of y21 once it is announced in Step 2, and we 
define the output function as being y2, then the protocol computes a network output which is f 
applied to the network inputs. 


What went wrong? Clearly protocol P, is not a “good” protocol. For in the ideal evaluation of f, a 
bad Player 2 has two disjoint options: he can either learn Player 1’s input (by choosing an even fake 
input), or he can control Player 1’s output (by choosing the desired odd input). In protocol P,, 
Player 2 can can both see Player 1’s input and control Player 1’s output. 


Input independence. A first explanation for this failure might be that the protocol P, was bad 
because it failed to achieve input independence: in particular, a “fake” value of x2 chosen by a bad 
Player 2 might depend on the private input of Player z,. For he who shares our point of view —that 
a secure evaluation should mimic as closely as possible an ideal evaluation— input independence 
must be either an explicit requirement of a definition of security, or (as in our case) a consequence 
of it; for independence ezists in an ideal evaluation, as the the adversary has no idea of the inputs 
of uncorrupted players when she chooses her substitutes for them. 

Realizing that a formalization of privacy and correctness, taken together, might not imply 
independence, several researchers have considered independence as an additional requirement to 
add along. 


Security # privacy + correctness + input independence. Though formalizing input independence 
in a robust and satisfying way is not trivial, we shall not need to in order to make our point: that 
disjointly requiring privacy, correctness, and independence is still inadequate to properly capture 
the idea of security. Let us demonstrate this by modifying our counterexample. 

Suppose, once again, that there are three players, each player i having a private input z; € 
{0,1}’. Consider the following function g that they may wish to jointly compute. For each i € 
{1, 2,3}, define 

Heeieo= lz, if the last bit of zz is a 0, and 
a ai 2z_ if the last bit of x9 is a 1. 


That is, each player is to learn the same string, either that belonging to the first player or second 
player, as determined by the parity of the second player’s input. The string which is released is 
tagged by the identity of the one who contributed it. 

We sketch a protocol P; below. Though somewhat artificial, other, “natural” protocols might 
suffer from the same defect which this one highlights. 

Our protocol makes use of a committal protocol. Roughly, this is a way to pin down an input 
while simultaneously keeping it secret. At a later stage, a decommittal protocol can be used to 
globally reveal exactly what was committed during the committal stage. References for this notion 
of a committal and decommittal protocol (the ingredients of a verifiable secret sharing) appear in 
the last footnote. 
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PROTOCOL Py: 


Step 1. Each player i commits to his private input, 2,;. 
Step 2. The last bit of zz is decommitted. 
Step 3. If it is a0, z, is decommitted. 
If it is a1, t2 is decommitted. 
Each party i outputs g,(z1, 22, 23). 
Step 4. Player 1 tells Player 2 his input, z,. 


Though we shall not formally argue it, protocol P, is private leaking g, correctly computes g, and 
achieves input independence. Still, the protocol is certainly wrong. The “mistake” is the inclusion 
of Step 4, which gives Player 2 information he does not deserve when z2 ends in a 1. 

The fundamental problem illustrated by this example is that privacy and correctness can be 
competing requirements, and a decoupled definition of security does not respect the possible inter- 
action of these two competing goals. 


MODEL OF COMPUTATION. Our definition implicitly fixes the model of computation to be that 
described—for example, the exposed state function, E, gives the current-round view (that is, “the 
standard model”). Other models of computation can be specified, each “automatically” giving 
rise to its own notion of security. For example, information-theoretic security, from scratch, in 
the complete-history model, is exactly as Definition 3.10 gives, except that the exposed-history 
function, EF, implicit in the definition, is the identity map. 


3.5 Incorporating History 


We now drop the first simplifying assumption listed in Section 1.7. Namely, we wish to take account 
of the fact that the players and the adversary may have a history dating back before the execution of 
the current protocol. Because of this history, a player may initially possess more information than 
just his private input, and an adversary may initially possess information correlated to the players’ 
inputs. We must capture the intuition that even in the presence of such extra information, the 
adversary can no more compromise a secure protocol than she can compromise the ideal evaluation 
which takes account of the extra information. For example, even if the adversary already knows 
the private inputs of all the odd-numbered players, and even if each even-numbered player i < n—2 
already knows the private input of player i + 2, still, a protocol should leak nothing more than it 
is “supposed to” under these circumstances. 


A HISTORY OF HISTORY. Concern that protocols be robust against such additional information 
in the hands of its agents has its roots in the auztliary input provided in the definition of a zero- 
knowledge proof systems. Auxiliary input is more than a “trick” to permit basic composition 
properties: it is an addition which mirrors the refined intuition. 

At the very beginning, the need for auxiliary input in a robust formalization of zero-knowledge 
was unnoticed by its creators, Goldwasser, Micali and Rackoff. They quickly discovered this issue 
included it in their paper setting forth the notion of zero-knowledge [GMR89]. Independently, 
Tompa and Woll [TW87] and Oren [Or87] realized that a good definition of zero-knowledge needs 
to have auxiliary input. 


MODELING HISTORY. Everyone needs a sense of history. Indeed, the adversary may initially 
possess certain information, and each player may have information associated to him at a protocol’s 
inception—this information becoming available to the adversary when she corrupts him. Mirroring 
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this, history is modeled as advice to the adversary, and as aurztliary input for each player. We 
remark that in our context, “auxiliary input” is a new technical term, different from the usage 
mentioned above, in the context of zero-knowledge proof systems. 

In the upcoming subsections, we first expand our explication of the auxiliary inputs. Then we 
explain adversary advice, and formally specify how to run a protocol in the presence of an adversary 
when the players have auxiliary inputs and the adversary has advice. In Section 3.5.3 we update 
our definition of security, giving a more refined notion for information-theoretic secure function 
evaluation than was Definition 3.10. 


3.5.1 Auxiliary inputs 


Underlying our notion of security from scratch is the idea that each player 7 comes into a collabora- 
tive computation having no past and with but one destiny—to compute some f;(z;,...,2,). With 
this in mind, we modeled the initial state of a player i as containing only his private input and his 
identity, s°° = z,#i. We said that when the adversary corrupts player i in a round r she learns an 
exposed state of containing some piece of 7’s history and the messages he is about to receive. 

To be more general, corrupting a player should be more rewarding. When the adversary corrupts 
a player i, she is handed some arbitrary information a; associated to him. This information might 
represent the history of that player before the execution began; or, it might be information irrelevant 
to the current task at hand (as in the “saved state” in a subroutine call) not modeled by the player’s 
computational state. 


PROTOCOLS RUNNING WITH ADVERSARIES. To incorporate this change into our model, to each 
player i we associate not only his private input, z;, but also his auziliary input, a;. A player 7 
cannot see his auxiliary input—only the adversary, when she corrupts him, is given it. By denying 
a player access to his auxiliary input we reflect the intuition that this is information which a good 
player does not need to use for performing the current computational task. 

Executing a protocol in the presence of an adversary now requires specifying the private input Z, 
the auxiliary input a, and the common input c. For simplicity, all auxiliary inputs are taken to be 
of the same length, which we denote by m. It is convenient to demand that this value appear, in 
unary, on the common input: say c = 1‘#1™. 

When a processor i is corrupted by the adversary in round r, the exposed state she receives is 
re-defined as 


r SFO ¥T; #0; ifr=0 “The exposed state of processor i at 
Sar eajemy*- 4m? «E(H{) ifr >0 round r. ” 


where, recall, m5, is the round-r message prepared by j for i, and E is the exposed-state func- 
tion. We re-define the configuration of a player to include the his auxiliary input; thus a player 
configuration is an element (s;, r;, a;) of 


{0,1} x {0,1}° x {0,1}° 
—e Saar ee 


player's future future 
state coins advice 


SIMULATORS RUNNING WITH ADVERSARIES. To devise a history-sensitive notion of security we 
must take account of auxiliary inputs in our notion of the ideal evaluation. Namely, in the ideal 
evaluation of f on input Z and auxiliary input @, when the adversary corrupts a player ? she learns 
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(z;,a;) if she has not yet substituted in her fake inputs. If she has substituted in these fake inputs 
and they were z7, then the adversary receives ((z;,a;), y), where 7 = f(r U 27). 

The changes to the rules in the ideal evaluation are reflected in the definition of the ideal- 
evaluation oracle. First we change the notation to O,(Z, 4), explicitly indicating the dependency of 
the oracle on the auxiliary input. The oracle behaves as follows: to a component query of i, if the 
valid function query has not yet been made then the oracle responds with (z2;,a,;); while if the valid 
function query 27 has already been made and # = f(r>U zz), the oracle responds ((z;,a;), yi): 

The notion of simulatability is unchanged, except, of course, that the oracle given to the simu- 
lator is now an O,;(Z,4@)-oracle, and the execution of a simulator with an adversary depends on the 
auxiliary input a. 


3.5.2 Adversary advice 


The adversary’s advice, denoted a,, can be thought of as information the adversary has come to 
know, somehow, before the protocol begins running. As shall be clear when we formalize security, 
the adversary’s advice may depend in an arbitrary way on the common input, the players’ inputs, 
and their auxiliary inputs. But it cannot depend on the random coin sequences which are issued 
to the players. 

(When we describe the complexity-theoretic notion of security in Section 5, the adversary’s 
advice will play an additional role: it will model nonuniformity which may be available to the 
adversary. See Section 4.3 for some discussion of this.) 

We model the adversary’s advice as an infinite string, which the adversary consumes bit-by-bit, 
in exactly the same manner as she consumed her random coin tosses. When a bit from a, is read, 
it vanishes from a, and augments the adversary’s computational state. 

To implement these ideas, we modify an adversary’s next-action function to allow her to get a 
single bit of advice from a4. The adversary is still permitted to perform all the actions she was 
previously permitted. Thus the adversary’s next-action function is now a syntactic function with 
the following domain and (expanded) range: 


N : {0,1}" — {compute, flip-coin, get-advice, corrupt, , ..., corrupt,, round-done}. 
current 
state 
We must also augment the notion of an adversary configuration, adding a component for the 
unconsumed portion of her advice. Thus an adversary configuration ($4,74,4a,%a) is an element 
of the set 
{0,1}" x {0,1}° x {0,1}°% x 20d. 
eee eee Ne —~ 


adversary’s future future corrupted 
state coins advice players 


CONFIGURATION SEQUENCES. Let A be an adversary for an n-party protocol, and let P be such a 
protocol. We describe how, from any common input c, player inputs Z, initial player configurations 
(CP°,...,C0°), initial adversary configuration C'%° = (84,74,4,4,%a), and exposed-state function FE, 
protocol P and adversary A generate a sequence of player configurations, {C;°: i € [l..n],r € 
[0..2]}, 9 € N}, and a sequence of adversary configurations, {C4’: r € [0..R],p € N}. 
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With all notation as before, the players’ computational states progress according to 


(Plecs"). ri? oa”) if N(s;’) = compute 
CPt) =f (start? rlerte.--, at?) if N(s%°) = flip-coin 

Cr? if N(s;°) = round-done 
CIM = (sitraMy, rie", af) 


while the adversary’s sequence of configuration is given by 
(A(c, 877), 777, af, we if N(s"?) = compute 


rp orp rp rp rp rp ‘fs AS OTP\ — : 
(sear, Teo ds ++, Gh, KA) if N( 3%) = flip-coin 


r(p+1) rp. orp orp orp orp rp\ +o At rP\ _ gr : 
Ca (SY *OK, Tas Daag, Ka) if N83’) = flip-coin 
(sfof, 2, ay, KAU {i}) if N(s%) = corrupt, 
Cy if N(s"?) = round-done 
(870474 Mi, fer are. Prlasde | ifr>oO 
corte 
A 


Oi iad ifr=0 
with the exposed state of as specified on Page 46. 


EXECUTING PROTOCOLS. An initial configuration of the network is now identified by a tuple 
(Z,d,a,,c, f,r,4), specifying the players’ private inputs z € ({0, 1})*, their auriliary input @ € 
({0,1}”)", the adversary’s advice a, € {0,1}, the common input c = 1*#1™, the players’ coins 7, 
and the adversary’s coins r4. For a given protocol P and adversary A, an initial configuration of 
the network determines an ezecution of P in the presence of A. This execution is the sequence of 
configurations {C7’, C4’} generate by P and A when the initial configuration of party 7 is taken 
to be C?° = (a; ft, r;), the initial configuration of A is (ka, Ta, @4 Ka), for Ky = Q, player i’s coins 
are r;, the adversary’s coins are r,4, the common input is c, and the players’ inputs are Z. 


3.5.3 Security (including history) 


VALID INITIAL CONFIGURATIONS. Not all tuples (Z,d,a,4,c, 7,74) denote valid initial configura- 
tions. In fact, under the conventions we have specified, the only initial configurations allowed are 
those having their first four components given by LJ, L,, where 


ly = LJ {(%Gaa,c): Z€ ({0, 1}")", fe ({0,1}”)”, aa € {0,1}, and 
n>3, £,l,m>0 ee 1EHI™}. 


Here, L, denotes the valid tuples (7,d,a,,c) having security parameter k. 


ENSEMBLES FOR SECURE FUNCTION EVALUATION. Given a fixed-round, n-party protocol P and 


—_- 


an adversary A, an initial network configuration (Z,@,a4,c, 7,74) determines the an execution, 
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and a corresponding adversary’s view. If 7 and r, are allowed to vary, then there is an induced 
distribution on these adversary views, which we denote by A-VIEW{ (2, @, a4,c). If (Z,d,a,4,c) are 
allowed to vary as well, then we obtain an ensemble £ A- VIEWS (2, d,a,4,c) over L = {L,}. 

Similarly, fix a function f : ({0,1}‘)" — ({0,1}')", an adversary, A, and a simulator, S, using 
an adversary input function AZ. Then each point (Z,d,a4,c) € Li, taken together with a set 
of adversary and simulator coins (r4,7s), determine an associated adversary view. If r4 and rs 
are allowed to vary, then there is an induced distribution on these views, which we denote by 
A-VIEW$4 (2, G,aa,c). If (@,d,a,4,c) are allowed to vary as well, then we obtain an ensemble 
EA-VIEWS“7! (2, a, a,,c) over L = {Ly}. 


NETWORK INPUT AND OUTPUT. For a given adversary A and protocol P, The adversary in- 
put and output formerly gave rise to functions AZ(Z,c,7,r4) and AO(Z,c,7,r4). Since our 
initial configurations are now somewhat richer, the awareness functions now give rise to func- 
tions AZ(Z,d,a,4,c, F,r4) and AO(Z,da,a,4,c, 7,74), specifying the adversary’s input and output 
that results from the given initial configuration. These function, in turn, give rise to functions 
AI (Z,@,a4,¢, 7,74) and AO(Z,a,a4,c, 7,74), exactly as before. 


SECURE FUNCTION EVALUATION. Using the language just introduced, we are now ready to de- 
fine what it means for a protocol P to securely evaluate a finite function f, ignoring issues of 
computational complexity. 


Definition 3.11 Let f : ({0,1}‘)" — ({0,1}')" be a function, and let P be an fixed-round, n- 
party protocol. We say that P statistically t-securely computes f, ignoring complexity, if there is a 
simulator S, a t-admissible adversary input function AT, and and an adversary output function AO, 
such that for any t-adversary A, 


e Privacy: EA-VIEW? (Z, a, a4,c) + EA-VIEWS4? 1 (z, d, a,c). 
e Correctness: There is a negligible function e(k) such that for all (Z,d,a,4,c) € Le, 
Prob [AO(,d,aa,c, 7,74) # {(AL(E,d,a4,c, 7,74))] < €(k), 


where the probability is taken over all possible Ff and r,. 


3.5.4 Remarks 


ON-LINE ADVICE. We remark that more general notions of adversary advice are possible than 
the one we have described here. For example, one could regard the adversary as being entitled to 
obtain information in installments, new information becoming available to her at each round and 
with each corruption of a player. The information she is entitled to in a given round or following 
a given corruption would be a string computable by an explicitly given, efficiently computable 
probabilistic map on the adversary’s current computational state, the common input c, the input 
vector Z, and the auxiliary input @. Though somewhat unintuitive, when embedded in the notion 
of a secure protocol, demanding robustness against such on-line advice appears to be a stronger 
notion of security. Though on-line advice may be necessary for a theory of secure protocols robust 
against running multiple protocols concurrently, we have chosen to stick with the simpler notion of 
an infinite adversary advice string, and finite auxiliary strings for each player, for reasons of ease 
of explication. 
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3.6 Incorporating Variability 


We now drop the second, third, and fourth simplifying assumption listed in Section 1.7. Namely, 
we no longer imagine that the number of players be fixed, that our functions be finite functions, 
and that a protocol run in a number of rounds R = R(c) which is independent of the random 
choices made during its execution. 

After describing each relaxation in separate subsections, we give a more refined definition of 
secure function evaluation than was Definition 3.11. It still ignores issues of computational com- 
plexity, but does not imagine that protocols are run, “from scratch,” by some fixed number of 
players, in some fixed number of rounds, their goal being to evaluate a fixed finite function. 


3.6.1 Variable number of players 


GENERAL PROTOCOLS. To properly talk about general multiparty protocols we must relax the 
requirement that a protocol is tailored for one particular number of players. Thus we consider 
a (general) protocol P to be a family of n-party protocols, P = {P,}. However, recall that we 
demanded that a protocol at least be reasonable to describe (that is, Turing-computable); in passing 
to general protocols, we would like not to lose this property. In fact, any “reasonable” protocol 
should have a description that is efficiently computable knowing the number of players involved. 
We demand this in our definition below. 


Definition 3.12 A protocol P is a polynomial-time computable function that maps a number 1” 
to a standard encoding of an n-party protocol Pp. 


(A nonuniform protocol fails to meet the “polynomial time” constraint above.) We suppress the 
subscript n when considering an n-party protocol P,, using P to denote either a general protocol, 
or the particular n-party protocol that it specifies, when n is understood. 

Now that the number of players may vary, we will always specify it on the common input. We 
briefly postpone describing its syntax. 


GENERAL ADVERSARIES. To talk about a general protocol under attack by an adversary we must 
suitably relax our notion of an adversary, too. In particular, we consider an adversary to be a 
collection of agents, the appropriate agent selected according to the number of players. As there 
was no requirement on the computability of the adversarv’s strategy, there is no computability 
requirement in determining the collection of functions whicu constitute an adversary. 


Definition 3.13 An adversary A is a function that maps a number 1" to an n-party adversary Aj. 


Once again, we suppress the subscript n when considering an adversary for an n-party protocol A,, 
using A to denote either a general adversary, or the n-party adversary A, that it specifies, when n 
is understood. 


3.6.2 Function families 


WHY FUNCTION FAMILIES? Though the secure evaluation of finite functions is not a trivial matter, 
it is not general enough. For example, dealing exclusively with such functions does not let us discuss 
“a secure computation for the mean salary”—since the number of players and how big their salaries 
might be has not yet been specified. To deal with such computational tasks, and to realize the 
full power of a dynamic adversary, we consider secure computations of families of finite functions. 
Our formalization of these objects constitutes one way to deal with infinite domains (rather than 
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({0, 1}‘)") while insisting, in any given execution, that the potential domain be finite. See the 
discussion at the end of this chapter for an explanation of why this is necessary. 


FUNCTION FAMILIES. Recall that a finite function is a map faz : ({0,1}‘)" > ({0,1}')", for some 
fixed values of n, £, and /. Our notion of distributively computing “arbitrary” functions is to use the 
common input to specify what finite function the current protocol is supposed to compute. In fact, 
a function family f is precisely a way to interpret each common input c = 1*#1°#1'#1'#17#C 
as a map f, : ({0, 1}‘)” + ({0,1}')". That is, 


Definition 3.14 A function family f is a map from strings to finite functions such that when c = 
Vee PL HI" #C, for some C € {0,1}", the finite function feZ flo) is a map f. : ({0,1}‘)" > 
({0, 1} )”. 


This viewpoint of what a function family is has two pleasant features. First, it expunges nonuni- 
formity issues from consideration: if you want to compute some function, it should be described 
on the common input, the complexity of producing such common inputs being irrelevant. Second, 
the viewpoint emphasizes that the encoding of a function is highly relevant to its computation: for 
example, it may be possible to securely compute a function under one encoding, but impossible 
under some other. 

As a consequence, the claim that a protocol securely computes a function family f must explic- 
itly fix how each common inputs c encodes its finite functions f,. On the other hand, a definition 
of the secure computation of f need not fix how common inputs encode functions; all that is im- 
portant is the relationship between the behavior of the protocol when the common input is c to 
the function f.. 


UNIVERSAL PROTOCOLS. Suppose the function family f is as follows: when the common input is 
c= 1*#1"#1'#1'#1"#C, and C encodes a Boolean circuit from ({0, 1}‘)" to ({0, 1}')", then f, 
denotes the mapping described by this circuit. If C does not properly encode such a circuit, then 
f, is some particular constant map. 

In this case, if there is a secure protocol to compute f then it is universal, in the sense that any 
family of finite functions has a natural encoding as a family of circuits. Other encodings are equally 
good and equally universal: C’ might be taken as a description of a Turing machine program, say. 

The existence of universal protocols will be discussed in Section XXX. 


3.6.3. Variable number of rounds 


In the ideal evaluation of a function f, one imagines that the computation takes a fixed amount of 
time, and therefore the players and the adversary know when the computation is over. Though we 
do not regard taking a fixed amount of time as being an important feature of the ideal evaluation, 
we do regard termination awareness as an important feature of it. 

Therefore, we relax the constraint that the number of rounds be fixed at some value A, depend- 
ing, if at all, only on the common input. Instead, we allow protocols to take a number of rounds 
which may vary with the random choices made in the execution. 

Since we wish to capture that all the participants should “know” when the computation is over, 
we might as well require that the computation be jointly terminating—that is, all good players 
halt within the space of a single player round. But this requirement alone would not be quite 
enough—because the adversary, too, should know when termination occurs. We can ensure that 
she does very simply, by demanding that termination be a function of the traffic of broadcasts. 

We describe below, without undo formalism, the changes used to implement these ideas. 
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REQUIRED CHANGES. We leave unchanged the notion of a protocol and adversary, but add a single 
player interaction function: a terminated function, 7. In defining the execution of a protocol in 
the presence of the adversary, r is applied to the vector of broadcast messages computed at the 
completion of a player round. When it evaluates to 1, the last round of player activity has just 
been completed, and the protocol terminates after the following round of adversary activity. At 
the end of this round, r must still evaluate to 1, regardless of what the adversary did. 

A protocol diverges if it never terminates, due either to an infinite sequence of micro-rounds, 
or to 7’s failure to signal termination. An admissible protocol never diverge, regardless of starting 
configuration. A protocol for secure function evaluation must be admissible. 

An R-round execution is one which terminates at round R. Adversary views include only the 
sequence of computational states up until termination. In defining the adversary output and the 
network output, the adversary output function, AQ, is applied to the adversary’s final traffic, while 
the players’ output function, 0, is applied to each player’s final computational state. 

In defining the interaction of an an adversary with a simulator, the simulator and the adversary 
together determine the broadcasts. The interaction function r can be applied to these broadcasts. 
Therefore, termination is an equally meaningful condition applied to adversary-simulator interac- 
tions as it was applied to adversary-network interactions, and quantities like the adversary view 
produced from conversations with the simulator are well-defined. An adversary-simulator interac- 
tion diverges if it does not terminate. We require that a simulator for secure function evaluation 
never diverges, regardless of the adversary with whom it interacts. 


WHEN BROADCAST IS NOT AVAILABLE. The notion above must be modified to be meaningful if 
broadcast is not permitted. In this case, a secure protocol must come equipped with a function 
7 which, applied to player i’s traffic T7, evaluates to either protocol-done or protocol-not-done. 
Applied to the adversary’s traffic T7, it also evaluates in this range. In an execution of a protocol 
with an adversary, these functions all evaluate to protocol-not-done—until the round at which they 
all evaluate to protocol-done. The function 7 can then be used as above. 

In the absence of broadcast, what is outlined above might be considered too much to expect, 
because of the impossibility of achieving constant-round secure protocols which it would entail. To 
avoid this, we can relax the definition further, and require only approzimate-termination awareness: 
namely, each player, and the adversary as well, must know when the protocol has terminated only 
to within a certain number of rounds, 6. This amount can be considered as a fixed polynomial of 
parameters specified by c, say. In an execution of a protocol with an adversary, these functions all 
evaluate to protocol-not-done and then to protocol-done—except for a “window” of up to 6 rounds, 
during which some may evaluate to protocol-not-done and others to protocol-done. The value of r 
can now be used as above. 


3.6.4 Security (including history and variability) 


VALID INITIAL CONFIGURATIONS. Not all tuples (7,d,a,4,c, 7,r,4) denote valid initial configura- 
tions. In fact, under the conventions we have specified, the only initial configurations allowed are 
those having their first four components given by LU), Ly, where 


Ps i U ((z, a, a8) He ({0, 1}')", ae ({0, iy"), a, € {0, 1}°, and 
n>3, L,m>0 c= 1*#1"#14#1'#1"#C, for C € {0, 1}"}. 


Here, L, denotes the valid tuples (7,@,a,,c) having security parameter k. 


52 


ENSEMBLES AND AWARENESS FUNCTIONS. For any protocol P, adversary A, function family f, 
and simulator S, we have associated ensembles 


EA-VIEW{(Z,d,a4,c) and €A-VIEW$4 (2, a, a,,c) 


over L = {Ly}, defined exactly mirroring the definitions of the corresponding ensembles of Sec- 
tion 3.5.3. 

For any protocol P and adversary A, each initial network configuration (Z,d4,a,4,c, 7,74) deter- 
mines AT(Z,d,a,4,c, f,r,) and AO(Z,d,a,4,c, 7,74), exactly as before. These, in turn, give rise 
to function AT(z, a, Ga,C, r, Ta) and A(z, a, Gayl, r, Ta): 


SECURE FUNCTION EVALUATION. We now revise our definition of secure function evaluation, still 
ignoring complexity issues but taking account of the extensions from this and the previous section. 


Definition 3.15 Let f = {f.} be a family of finite functions, and let P be a protocol. We 
say that P statistically t-securely computes f, ignoring complexity, if there is a simulator S, a t- 
admissible adversary input function AT, and an adversary output function AO, such that for any 
t-adversary A, 


© Privacy: EA-VIEW; (2, a,a4,c) > EA-VIEW?'“?! (2, d, a4, 0c). 
e Correctness: There is a negligible function e(k) such that for all (Z,@,a,4,c) € Le, 
Prob [AO(z,a,a4,¢, #,ra) # f(AL(Z,a,a4,¢, 7,r4))| < €(k), 


where the probability is taken over all possible F and r4. 


3.6.5 Remarks 


VARIABLE NUMBERS OF PLAYERS. Varying the number of players is more than a nicety to neatly 
handle functions on larger domains: it is a necessary relaxation to our notions if ve are to realize 
the true power of our adversaries. 

Roughly said, for any fized number of players, security with respect to the class of “powerful” 
(dynamic) adversaries we have described is equivalent to security with respect to the class of “weak” 
(static) adversaries who behave as follows: they choose the set of players they will corrupt at the 
beginning of the protocol, before any players are corrupted; then they corrupt exactly this set of 
players. The equivalence of static and dynamic adversaries when the number of players is fixed 
shall be proven in an expanded version of this paper. 

On the other hand, when n is allowed to vary the situation is exactly the reverse. Namely, 
there exist protocols which are (provably) secure with respect to a static adversary, but (provably) 
insecure with respect to a dynamic adversary. In an expanded version of this paper, a protocol 
having this property will be described. 


FUNCTION FAMILIES. Similarly, dealing with families of functions is important to the notion of 
security. Informally, there exists a protocol P and a function family f = {f.} having the property 
that for any c, the protocol P when run on an initial configuration having common input ¢ securely 
computes the finite function f,. All the same, the protocol does not securely compute f. An 
example of this phenomenon will be described in an expanded version of this paper. 
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TERMINATION AWARENESS. The requirement that players and their adversaries “know” when a 
computation is over is necessary, for example, to make a sensible notion of serial composition. It is 
necessary for our reducibility theorem, as well. Of course, a meaningful notion of security can still 
be given which does not demand this property. 


KNOWING THE INPUT LENGTHS. Notice that, whatever our computational task, all players know 
how long other players inputs are. Though we need not be quite so demanding, it is essential 
that the players at least know a bound on the length of the longest possible private input. As 
long as such a bound is known, we can take all inputs to be of the same length, as a matter of 
convenience; but if such a bound is not known, and one is unwilling to reveal this information in 
the course of a “secure” protocol, then problem of secure computation changes markedly, and many 
computational tasks become impossible. (See [CGK90] for work on the problem within this more 
restricted framework.) The cause for this, intuitively, is that for some functions f, a communication 
protocol to distributively evaluate them must divulge not only the function value itself, but also 
a bound on the length of its inputs: for one thing a player i learns when interacting with another 
player 7 is the number of bits which were sent out by 7 and received by i, and, for some functions, 
this number of bits will have to be as many as j’s input is long. 

As a consequence, to arrive at a generally obtainable notion of security, one has the choice 
between developing a notion of a secure function evaluation which “leaks nothing except the function 
value and a bound on the input length,” or, alternatively, one that “leaks nothing beyond the 
function value, where a bound on input lengths is known by everyone ipso facto.” We have adopted 
the second viewpoint. 


3.7 Discussion 


Discuss the following points: 


Doing nothing is not a secure computation of the constant function. Ezplain why it shouldn’t 
be. 

Weaker notions of security, as in [KMR90]. 

More “direct” mimicking of ideal evaluation, as in [GL 90). 

Simulators in our contezt vs. zero-knowledge: why the differences? 
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4 Complexity 


This chapter —particularly Section 4.4— is to be substantially revised. 

This section describes a relaxed definition of security, called computational security. Though 
an information-theoretically secure protocol is necessarily computationally secure, the reverse need 
not hold, as computational security only captures immunity against those t-adversaries which are 
limited to performing reasonable computational tasks. 

The broad strokes for relaxing our notion of security are straightforward, so we sketch them now. 
We say that reasonable adversaries are those which run in polynomial time, and a computationally 
secure protocol only considers the injurious effects such agents. As expected, a computationally- 
secure protocol must be efficiently simulatable given the appropriate ideal-evaluation oracle. But 
instead of saying that interacting with this simulator produces nearly an identical view as interacting 
with the network, we permit the distribution on views to be quite different, as long as these 
distributions appear the same to observers limited to efficient computation. Computationally- 
secure protocols must achieve the same correctness condition as information-theoretically secure 
protocols, but they do this with respect to efficiently computable awareness functions, AZ and AO. 

The main subtlety in defining computational security lurks in this last sentence: we must 
modify our adversary input and output functions very carefully, or else we do not arrive at a 
model-independent notion of security which preserves our reducibility theorem. The new notions 
for awareness functions are described in Section 4.4. 

After having defined this more liberal notion of security, we also define a less liberal one, called 
perfect security. Though perfect security, like perfect zero-knowledge, is more cumbersome to work 
with than its statistical counterpart, it is always good to understand what perfect security is and 
when it can be achieved. 


4.1 Polynomiality of Algorithms 


We follow well-entrenched tradition, regarding deterministic functions as computationally tractable 
exactly when they can be computed by Turing machines running in polynomial time. 

It is convenient to speak of computable functions of several inputs, some of which may be 
infinite strings. For example, a probabilistic encryption function is such an object (page 40). For 
functions on possibly infinite strings, we explain the meaning of “polynomial time” below. 

A Turing machine is a device with some number of input tapes, a single output tape, and a finite 
control. Roughly said, a Turing machine M computes a function M(z,,...,2;) if, when input tape? 
is initialized to z;, the execution of M always halts with output tape containing M(2,...,2;). 
Notice that the function M may be defined on any fixed number of finite or infinite strings. 

For Turing machine M to compute the function M in polynomial time, we require M com- 
pute M, halting after a number of finite-state transitions bounded above by some fixed polynomial 
in the length of M’s first argument, z;. 

Recall that we have made the common input the first argument to n-party protocols, adversaries, 
and simulators. So, in all these cases, polynomiality means polynomial in ||. 


4.2 The Complexity of Protocols and Their Adversaries 


Micro-rounpDs. Let e = {Cj°’,C%’} be an execution of an n-party protocol, terminating at 
round R. The number of player micro-rounds for this execution is the number of micro-rounds 
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utilized by uncorrupted processors: that is, it is 


n R 
ee 


tel rei 


where 


, _) 0 if J? <r such that i € KP 
Gir = Qi, otherwise 


The player micro-round complezity is a function of the common input, c. It gives the worst-case 
number of player micro-rounds when the common input is c, and is “oo” if no such number exists. 
By “worst case” we mean the maximum over all executions of the protocol interacting with any 
adversary. 

Similarly, the number of adversary micro-rounds for an execution e is 


R 
ZS Oar: 
r=0 


The adversary micro-round complerity is a function of the common input, c. It gives the worst-case 
number of adversary micro-rounds when the common input is c, and is “oo” if no such number 
exists. Here, “worst case” gives the maximum over all executions of the adversary interacting with 
any protocol. 


Rounps. The round complezity of a protocol P is a function of the common input, c. It gives the 
least value R such that when protocol P is run in the presence of any adversary A and the common 
input is c, the execution necessarily terminates within R rounds. The round complexity is “oo” if 
no such number exists. 


COMMUNICATION BITS. The communication complezity of a protocol P is a function of the common 
input, c. It gives the least value js such that when protocol P is run in the presence of any 
adversary A and the common input is c, the total number of bits sent out by uncorrupted processors 
is at most yu. The communication complexity is “oo” if no such number exists. The number of 
communication bits for a specific R-round execution is defined as )<7_, 7), (|Mi| + Dy=1 1,1), 
using the definitions from Page 22. This expression counts all of the bits sent by processors before 
they are corrupted. 


POLYNOMIALITY OF PROTOCOLS AND ADVERSARIES. A protocol is polynomial time if each micro- 
round can be computed quickly, and there are not too many of them. More formally: 


Definition 4.1 A protocol P is polynomial time if there is a polynomial Q such that 


e For any n, the n-party protocol P,,(c,s) evaluates within Q(|c|)-time, where c is the common 
input. 


e For each n, the player micro-round complexity of P,, is bounded above by Q(|c|). 


Analogously, an adversary A is polynomial time if she is easily described, each micro-round is easy 
to compute, and there are not too many of them. More formally: 


Definition 4.2 An adversary A is polynomial-time if there is a polynomial Q such that 


e For any n, the encoding of A, is computed by A in time bounded above by Q(n). 
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e For any n and common input c, the adversary micro-round complexity of A,(c,s) is bounded 


above by Q(|cl). 
e For any n, the algorithm A,(c, 8) evaluates within Q(|c|)-time. 


Note that, under our definitions, a protocol can be polynomial time even though it may interact 
with an adversary who “floods” the network with a superpolynomial number of communication 
bits. 


4.3. The Complexity of Distinguishing Ensembles 


ALTERNATIVE DEFINITION OF INDISTINGUISHABILITY. We being by rephrasing our definition of 
indistinguishability in a way which generalizes better for handling issues of computational complex- 
ity. This notion is based on the idea of a distinguisher, the formalization of a “judge” who votes 
to decide among two competing alternatives. 

A distinguisher D* is a {0,1}-valued function D on some number of input strings, 21,...,2;, 
an infinite advice string, a, and an infinite sequence of random bits, rp. By ED*(2,...,2;) we 
denote the expected value of D, over its random bits rp, when the inputs are z,,...,z; and the 
advice is a. This is precisely the probability that D evaluates to 1. The following definition of 
indistinguishability is easily proven equivalent to Definition 3.8. 


Definition 4.3 Ensembles E and E’ are statistically indistinguishable, written E ~ E’, if they are 
over the same parameter set £ = {L,}, and for every distinguisher D*, 


e(k) = ip |ED°(1*, E,(w),w) — ED%(1*, Ey(w), w)| 


is negligible. 


COMPUTATIONAL INDISTINGUISHABILITY. We now specify what it means for two ensembles to be 
indistinguishable to an observer with bounded computational resources, thereby relaxing the notion 
of statistical indistinguishability of Definition 4.3. 

Recall that a distinguisher D* is a {0,1}-valued function D on a set of inputs, Z1,...,2,, an 
infinite advice string, a, and an infinite string of coin tosses, rp. We say that a distinguisher D® is 
polynomial-time if D is a polynomial-time algorithm. Computational indistinguishability demands 
negligible bias in distinguishing ensembles based on such resource-bounded algorithms: 


Definition 4.4 Ensembles E and E' are computationally indistinguishable, written E ~ E’, if they 
are over the same parameter set C = {L,}, and for every polynomial-time distinguisher D* 


e(k) = sup [ED*(1', E,(w),w) - ED*(1*, E(w), 
wel, 
is negligible. 


When we wish to emphasize the parameter set £ = {Z,} which parameterizes the ensembles EF 
and E’ we write E = E’. 
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4.4 The Complexity of Awareness 


In this subsection, we discuss what it means for a computationally bounded adversary to know 
something about an interaction. The intuition we are trying to capture is that the adversary knows 
some information if she could compute it “on the side,” without much extra expenditure of effort 
and without knowing much about herself at all. 

Our notion of awareness is very demanding, for a variety of reasons. First: because we wish 
to make minimal assumptions about what an adversary, as a devise, actually is and can do. For 
example, we certainly do not wish to assume that an adversary has a description of herself as a 
Turing machine, for example, or that she might “know” something only if she knows exactly her 
own nature: if we take our anthropomorphization seriously and our adversary actually is a person, 
such an assumption is highly questionable! For the same rationale, our adversary should not be 
able to “reset herself,” “see her coin flips,” or figure out what she would have done in the distant 
past or distant future. Second: our notion of awareness is strong in order to facilitate dealing with 
complexity concerns at very fine level, if we choose to. As an example, if an adversary interacts 
with an agent using just linear computational complexity, but she “knows” some information in the 
sense that she could compute it using some cubic-time algorithm, then it might not, in fact, “know” 
the information in a very real sense—her computing it may simply be impractical. Third: we must 
adopt a rather stringent notion of awareness or we no longer know how to prove our reducibility 
theorem. 

The idea that an interaction might establish that an agent “knows something” was put forward 
by Goldwasser, Micali and Rackoff [GMR89] and formalized by Feige, Fiat and Shamir [FFS87], 
and Tompa and Woll [TW87]. However, our notion of awareness differs from ideas to be found 
there. For one thing, the goal is different: we are discussing proofs of knowledge of a function 
associated with the interaction itself, as opposed to proofs of knowledge of a witness to a boolean 
predicate, say. Apart from this, we wish to be more demanding than in previous work, for the 
reasons given above. 


4.4.1 Informal description 


We are interested in knowledge associated to an interaction—principally, the knowledge an adver- 
sary possesses when she interacts. We thus make the following definition. 


Definition 4.5 An (adversary) awareness function F is a map 


F: {0,1}° x {0,1}° > {0,1}". 
—aw — —— 


common = adversary value 
input traffic known 


If F is not as above because its range is not {0,1}*, we still call F an awareness function, as long 
as its range has a natural encoding into {0,1}°. As an example, the adversary input and output 
functions were awareness functions. 

An adversary A interacts with an agent B who send messages to A and receives messages from 
her. We have described in detail the interaction of an adversary with two types of agents: protocols 
and simulators. In defining awareness, we may imagine an adversary A interacting with an arbitrary 
agent—but for simplicity we will jump back, in a bit, and take this agent to be a network running 
a protocol P. The nature of the interaction between A and B may depend on some parameters—in 
fact, the interactions we care about are probabilistic functions of w = (7, a, a,,c). 

An interaction of an adversary A with an agent B will be denoted A + B. To emphasize some 
parameter w on which this interaction depends, we write A > B. 
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ALGORITHM F4(c; a1, (;,...,@,): 


The algorithm is given c and does some computation. 
for i-1ltos-—l: 
until the algorithm is satisfied: 

It is given aj, J,,...,a;. 
It must compute a sample Gi — (A & B)[a;, f,,..., a]. 
The algorithm is provided a sample from (A > B)[ay, Bi,.--, a, fi). 
It does some more computation. 

It outputs a value, y. 


Figure 3: The structure of a probabilistic algorithm F for extracting knowledge from an agent A 
about traffic T. The algorithm is given input c and is “trying” to compute F(c,T). The traffic 
T= (a1, B,,...,a,) 


An A & B interaction can be described as follows: A sends to B a string a, (consisting of 
a corruption request corrupt; or a vector of messages on behalf of currently corrupted player M); 
then B responds with a string 3, (consisting, presumably, of an exposed state or a vector of messages 
on behalf of good players, respectively); then A sends another string, a2; then B responds with a 
string, G2; and so forth, until A sends some last string, a,, to the agent B. 

Now, for any w, not only is there is a distribution on possible A © B interactions, but, fixing 
an initial segment a, (,,...,0;, there is a distribution (A —% B)[a1,(,,...,a;] on possible next 
messages (3; returned by B. Likewise, there is a distribution on any (A > B)[ay, (,,..., 3] 

What does it mean for an adversary awareness function F to be efficiently computable (with 
respect to the agent B)? Roughly, there must be fized probabilistic polynomial time algorithm F 
(which one might imagine “embedding” in A) which is almost always able to compute F “on the 
side,” as A interacts with B. The algorithm F does this by playing the following simple game. 
As the conversation between A and B progresses, after A has already engaged in some partial 
conversation 7 and has just heard a message @ from B, the algorithm F may choose to concoct 
some different message 6’—but one drawn from the same distribution as the last message that B 
just sent. Algorithm F may then use A as a “black box”to figure out what message A would 
respond on the conversation in which the last message was ’ instead of @. (Each time A is so 
invoked, independent random coins are used for it.) Algorithm F may run this experiment several 
times, getting various sample replacement messages (3, 3”,.... However, this is the only manner 
under which F may experiment with the black-box A. At the end, F outputs it “guess” of F(c,T). 

Basically, we say that an adversary A is efficiently aware of an awareness function F arising 
from interactions with B under the condition that F(c,T) can be computed by a probabilistic 
polynomial-time alternative sampling algorithm—which is a algorithm having the structure de- 
scribed in Figure 3. 


Definition 4.6 Fix t € N. An adversary awareness function F for interacting with a protocol 
P is efficiently computable (with respect to t) if there exists a probabilistic polynomial time on- 
line alternative sampling algorithm F such that for any polynomial-time t-adversary A, for some 
negligible function ¢(k), for any (Z,@,a,,c) € Ly, with probability at least 1 — «(k) the following 
even happens: if T is a transcript drawn from by allowing A and P to interact with a configuration 
with (Z,d,a,4,c), then F4(c,T) outputs F(c,T). 


For a computational notion of security, not only do we allow allow the adversary input and output 
functions to depend on the adversary A in this “controlled” but efficiently computable way, but 
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we allow the same of the simulator. That is, recall that, in our previous definitions of security, 
the simulator S had no information whatsoever about the adversary with whom it was interacting 
(apart from that which could be inferred by the messages this adversary sent out). Now, we allow 
the simulator to compute its messages to A by allowing S to bea 

Namely, the simulator S, has an “oracle” for the adversary A with which it interacts, considered 
as a probabilistic algorithm that S to be a probabilistic polynomial-time on-line alternative sampling 
algorithm. We call such a simulator an efficient simulator. 


4.4.2 Formal description 
4.4.3 Remarks 
4.5 Computational Security 


SECURE FUNCTION EVALUATION. We now give our notion of computational security. 


Definition 4.7 Let t € N, let f = {f.} be a family of finite functions, and let P be a protocol. 
We say that P computationally t-securely computes f if there is an efficient simulator S using an 
efficiently-computable t-admissible adversary input function AT, and an adversary output func- 
tion AO, such that for any t-adversary A, 


© Privacy: EA-VIEWS (2, 4,a4,¢) EA-VIEWS 474 (2, @, a4, 0). 
e Correctness: There is a negligible function e(k) such that for all (Z,@,a4,c) € Le, 
Prob [AO(z, G,a4,c, 7,ra) # f(AT(Z,a,a4,¢, F, r4))| < «(k), 


where the probability is taken over all possible F and r4. 


4.6 Statistical Security 
4.7 Perfect Security 


PROBABILISTIC ALGORITHMS. A probabilistic algorithm M is a Turing machine which takes some 
number of inputs, z,,...,2;, and an infinite sequence of “coin flips,” r. It is required that for any 
set of inputs, M halts with probability 1, where the probability is taken over all choices of r. Thus, 
fixing any set of inputs z,,...,2,;, probabilistic algorithm M induces a distribution on outputs, 
M(2,,..-,2i)- 

There is no widespread agreement for a robust and generally adequate notion of an efficient 
probabilistic algorithm. Requiring that a probabilistic algorithm run in fixed polynomial time is 
usually adequate, but in some cases this is too restrictive. For example, simulators for perfect 
zero-knowledge proofs often do not run in fixed polynomial time, but we still want to demand that 
they be “efficient.” The same problem arises in our context: a perfect notion of security requires 
something more generous than fixed polynomial time simulation. 

When fixed polynomial time is inadequate, it is common to relax the notion to expected poly- 
nomial time. This is often a poor solution, for a variety of reasons: 


e First, expected polynomial-time is not a very robust notion. For example, the composition of 
expected polynomial time algorithms is not necessarily expected polynomial time. This lack of 
robustness leads, for example, to an unaesthetic and conceptually questionable asymmetry in 
the definition of perfect zero-knowledge: allowing simulators to be expected polynomial-time 
while verifiers are required to be fixed polynomial time. 
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e Second, expected polynomial time can be too liberal a notion. For example, for any constant c, 
an expected polynomial time algorithm might take longer than n‘-time for a non-negligible 
fraction of the possible random strings. Arguably, such behavior should be considered unac- 
ceptable in an algorithm termed “efficient.” 


e Finally, expected polynomial time can be an insufficiently liberal notion. For example, an algo- 
rithm which is linear-time —apart from the fact that it diverges with negligible probability— 
is a pretty efficient algorithm! But it is not expected polynomial time. 


To address such issues, we say that a probabilistic algorithm M(z,...,2;,7) is polynomial-time if 
there exists a fixed polynomial Q and a negligible function € such that for any (2,,...,2;), with 
probability at least 1 — ¢(|z;|), algorithm M halts within Q(|z,|)-steps. That is, M almost always 
halts in fixed polynomial time. 

We note that the class of probabilistic polynomial time algorithms is closed under composition; 
that such algorithms are robust against changing their behavior on a negligible fraction of random 
coin sequences; and that such algorithms would seem to be adequate for most simulation purposes. 


4.8 Discussion 


NONUNIFORMITY. The notion we have defined for computational indistinguishability is a nonunt- 
form notion—possibly, the ensembles appear different to the resource-bounded judge only by virtue 
of the infinite advice string, a. Nonuniform notions of indistinguishability have more commonly 
been defined by polynomial-size circuit families. We find the phrasing above more convenient, 
because of it more natural to allow an infinite string to be an input to algorithm than to a circuit. 

Uniform notions of computational indistinguishability—where the distinguisher does not have 
benefit of the advice a—are also possible. In fact, all notions and results of this paper have analogs 
in the uniform model, and it is not difficult to make the appropriate extensions. For economy of 
notions, we choose to describe only the nonuniform notion of security. This means that not only 
are the adversaries we consider restricted to nonuniform efficient computation, but, mirroring this, 
the the underlying notion of security is nonuniform as well. 


WHY PREFER NONUNIFORMITY? In our context, nonuniform notions of security have several 
advantages over their uniform counterparts. Most importantly, since a cryptosystem is generally 
run for a particular choice of security parameter, one would be unhappy with a protocol which was 
only secure against uniform adversaries: a sufficiently committed attacker would mount an attack 
that would break the cryptosystem itself, a much worse break than just breaking a particular usage 
of the cryptosystem. Secondly, proofs are frequently simpler or more natural in the nonuniform 
model. Third, existence results on secure protocols talk about how an arbitrary circuit can be used 
to specify a protocol for securely evaluating it; thus there is already nonuniformity present in the 
families of circuits which might be evaluated. 
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5 Properties of Secure Protocols 


This chapter is to be substantially revised. 

This section describes some of the basic properties which secure protocols enjoy. After some 
basic results on indistinguishability in Section 5.1, we begin, in Section 5.2, with the observation 
that in a secure protocol for computing f, when run in the presence of an adversary that is only 
“nosy” (that is, as she corrupts players, she continues to perform computation according to the 
protocol), each player i almost certainly outputs f,(Z). In Section 5.4 we show that, in a secure 
protocol, what the adversary commits to is essentially independent of input values held by good 
players, as it was with the abstraction which a secure protocol endeavors to imitate. In Section 5.3 
we show that the level of generality necessary for designing secure protocols for doing vector-valued 
secure function evaluation is already present in the seemingly simpler task of doing string-valued 
secure computation; in particular, vector-valued secure function evaluation can be implemented 
on top of string-valued secure function evaluation in a “generic” and efficient manner. Finally — 
and most importantly— in Section 5.5 we show that modular design of cryptographic protocols is 
possible, in the sense that if you design a secure protocol for computing some function g, you may 
thereafter treat g as a “primitive” operation available to you in designing other secure protocols. 
This reducibility property is the center of our notion of security. 


5.1 Preliminaries 
We state without proof some basic properties of indistinguishability. 


Proposition 5.1 If two ensembles are perfectly indistinguishable, they are statistically indistin- 
guishable. If two ensembles are statistically indistinguishable, they are computationally indistin- 
guishable. = 


Proposition 5.2 Computational indistinguishability of ensembles forms an equivalence relation. 
So does statistical indistinguishability and perfect indistinguishability. a 


The following definition and lemma capture the notion that if two ensembles are computationally 
indistinguishable, then the ensembles appear different even when sampled by selecting the param- 
eter according to an arbitrary distribution. The same assertion holds for statistical for perfect 
indistinguishability. 

Definition 5.3 Let A and B be ensembles, and let I = {I,: k € N} a family of probability 
measures on {0,1}". We say that A and B are statistically indistinguishable over [ if A and B are 
ensembles over the same parameter set, £ = {L,}, and support I, C Ly for all k, and for every 
distinguisher D*, 


e(k) = |Ey1,ED°(1", A,(w),w) — E71, ED*(1*, B,(w), w)| 


is negligible. They are computationally indistinguishable over C if the same assertion holds for 
every polynomial time distinguisher D*. 


Lemma 5.4 Let A and B be indistinguishable over L = {L,}. Then for any family of probability 
measures I = {I,}, where support J, C Ly for all k, A and B are indistinguishable over I. a 


We next note that computational indistinguishability coincides with statistical indistinguishability 
in one natural setting—when the support of the ensemble grows very slowly (or not at all) in 
the index of the ensemble. Such ensembles arise when, for example, a predicate is applied to an 
ensemble, and the image is considered an ensemble once again. 
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Lemma 5.5 Let A be an ensemble over £ = {L,} such that, for some constant c, support A,(w) C 
{0, 1}°'8* for all k € N,w € Ly. Then A and B are computationally indistinguishable if and only 
if they are statistically indistinguishable. a 


Last of all, we state a technical assumption under which a particular “composition” lemma holds 
on indistinguishable ensembles. 


Lemma 5.6 Suppose €A,(z) = EA,(z), support A(z) C L4, support Aj(z) C Li, 


EB, (2,y) Foe Bi(z,y), with B,(z,y) and BiY(z,y) are polynomial-time samplable. Then for 
any constants c, € Ly, E By (ce, Ar(z)) = EBy,(cze, Ae(z)). a 


5.2 Correctness in the Presence of Passive Adversaries 


A particularly sedate type of adversary is one that is “honest-but-curious”; such an adversary, 
when she corrupts a player, continues to execute the protocol faithfully on behalf of that player. 
(As always, such an adversary may choose whom to corrupt using an adaptive strategy.) As 
expected, when a secure protocol is run under attack by such an adversary, each player almost 
always computes the correct function value, as determined by the initial input vector. We state 
and argue this in the full paper. 


Theorem 5.7 Suppose P t-securely computes a function f = {f.}, and let A be an honest-but- 
curious t-adversary for P. Then, when P is run in the presence of A, for some negligible function 
e(k), for a fraction of at least 1 — €(k) of all (Z,@,a,,c) € L, each player i outputs ((f.)(Z))- 


Proof: Consider P being run in the presence of the “void adversary,” Ao, who corrupts no players 
whatsoever. Let 5 be the simulator establishing P’s security. Since the adversary input function AZ 
provides a value 27 where the set T consists precisely of the currently corrupted players, and since 
the set of currently corrupted players must be void, we know that AZ is identically equal to 
@. Consequently, the network input AZ is identical to the input vector Z, and the correctness 
constraint for P run in the presence of adversary Ao says that, for some negligible function «(k), 
for all (,d,a,,c) € Ly(f), with probability at least 1 — €(k) each processor i will output (f.(Z)). 

Now consider P being run in the presence of the honest-but-curious t-adversary A. Because 
this adversary executes the protocol P faithfully on behalf of each corrupted player, we know that 
the distribution on outputs of processors when running under attack by the void adversary Ap is 
identical to the distribution on outputs of processors when under attack by A. Thus the conclusion 
regarding the distribution on outputs for P under attack by Ag holds equally well for P under 
attack by A. | 


5.3 Completeness of String-Valued Computation 


The following theorem justifies, in some instances, restricting attention to the computation of 
string-valued function families. For its statement, we let f' be the function family of string-valued 
functions, encoded as boolean circuits, and we let f be the function family of vector-valued func- 
tions, encoded as boolean circuits. More specifically, we let the function family f’ = {f{} be 
described as follows: for a common input ¢’, a function f.: ({0,1}*")"* — {0, 1}'" is described 
by a boolean circuit C.» over bounded fan-in gates and unbounded fan-in XOR gates. Each func- 
tion f., can also be interpreted as a vector-valued function simply by replicating its output for 
each player. The function family f = {f.} is the one which maps any common input c to a func- 
tion f.: ({0, 1}“*)"* — ({0, 1}')"* described by a boolean circuit C, over bounded fan-in gates and 
unbounded fan-in XOR gates. 
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Theorem 5.8 Suppose that there is an O(depth(C,))-round protocol P that t-securely computes 
f. Then there is an O(depth(C‘))-round protocol P’ that t-securely computes f’, where 


Proof: This proof is a remnant of notation past. It requires substantial updating, and is left here 
only to give some idea of the argument involved. 

We must describe a protocol P = {P,} and show that it securely computes f = {C,,;}. 

The basic idea is very simple: P is derived from a protocol P for some deterministic function 
f related to f, as follows: each party i inputs into the computation of f a random pad p; which 
is XOR’ed with his “own” piece of the output. The is done so that the part of the output which 
“belongs” to a good player is not meaningful to the adversary, but it is still easy for the good player 
to interpret what his private output is. 

We now proceed to make this idea precise, and prove that it works. 


Definition of f. 
Define the string-valued function f = {C,. : ({0, 1}‘)" — {0, 1}°} according to 


Cy a(21p10140", « e+) Zn Pn 01407 ) 
(pr®Cn e(Z)) (1: + *(PnOCn e(Z)) [(n — LE + 1: né] 08 
pec, (Zz) 09, 


I 


where 
é is the value that occurs most among {4;,..., ln}, 
[z;| a pil = 6, 


g=- nl, and 

P= P= Pi-**Pn = (Diy--+) Pn). 
Note that we have assumed an encoding of Cas for which y = C,,,(Z) specifies, consecutively, the 
outputs of each of the players. Also, we do not distinguish vectors, such as (p;,...,Pn), from the 
corresponding string Pi .--Pn- 

For values C’, ; which are not well-defined by the expression above (for example, there is no 
unique £, é is too small, etc.), assert that Chi = 04. 

We remark that f = {C,, a} has polynomial-size circuits; the only observation needed is that Cra 
is defined in terms of fewer than é different circuits {Crehecg, each having size at most poly(né) < 


poly(né). 


Definition of the protocol P. 


Let P be a t-secure protocol for f. Protocol P,,¢ is as follows: each player i, on input z; € {0, 1}, 
flips coins to determine a random string p,, 


pi — {0,1}'. (1) 
Player : defines 
é = max{3é + 1,né}, and (2) 
7 = @- (3l+41). (3) 
Player 7 runs Py ij on input 
2,p;01'0". (4) 
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However, instead of outputting the string y which P specifies to output, player i outputs 


Outline. 

We must show that P t-securely computes f. Let A be a polynomially-bounded adversary. We 
must construct an on-line simulator S$ for A. Let $ be the on-line simulator showing that A does 
not defeat P, and let X be the associated committal function for A attacking P. The simulator 
S for P is made by modifying $. As the most apparent obstacle, note that 5 has access to an 
O,(Zps; f)-oracle, whereas S has access to an O +(Z; f)-oracle. 

The simulator S$ will behave like $, with a few exceptions. First, its queries to its O,(zps; f)- 
oracle will be answered by an oracle 2, which the simulator 9 itself will provide, using access 
only to its O,(z; f)-oracle. Secondly, simulator S, instead of producing transcripts with “output 
strings” y in the simulated views, will produces transcripts in which the string y is replaced by 
yi = yl(i — 12+ 1: if]@p;, where p; is taken from the simulator’s output. Last of all, instead 
of producing transcripts in which 2z;p,;3; appears as a player’s input, S will produce transcripts in 
which z; appears as the player’s input, and p; prefixes the player’s random coins. 

To prove that the simulator § “works,” we will establish the following sequence of implications, 
for protocols, simulators, and oracles which we shall shortly define. 


VIEW apa © Sag? > (6) 
VIEW Ka) pa) 2% SME (7) 
ee (8) 
VIEW h(a) SAY) (9) 
= soe (10) 


The Protocol P. 

We begin by defining a probabilistic analog of P, the protocol P. Each player i, executing P,.; 
on input 2; € {0, 18 os begins by flipping coins to determine p; according to Equation 1. Player 7 
defines @ and y according to Equations 2 and 3, sets s; = 01407, and runs P, 24 OD input 2,7; 3;. 
Player i outputs the string y which P computes. 

In other words, P is identical to P, except that P outputs the string y; = y[(i—1)€+1: c4]Op,, 
whereas P just outputs y. 


The oracle 0. 


We next consider a probabilistic analog @, to the oracle O,(Zp3; f). Oracle © behaves as follows: 
it selects random 


p ({0,1}*), (11) 
defines ¢ and ¥ according to Equations 2 and 3, and sets 
5 = (01'07)”. (12) 


The oracle then behaves like an O (aps f ) oracle. In particular, to a component query of ¢ preceding 
the output query, 2 responds with z;p,5;; to an output query of 7p,5p, Q responds with y = 
f(ZpP psp U fzPr5p); and to subsequent component queries i, 2 responds (z;p;3;, yi): 
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The simulator S. 

The simulator S$ is identical to $, apart from the encoding of transcripts. Namely, suppose, 
that $, when interacting with its oracle, produces a transcript r. The transcript T specifies (among 
other things), for each corrupted processor 7, i’s private input z,;p;3; and a portion of 7’s random 
tape, R;. Simulator $ outputs the same transcript r, except that each player i’s input tape is taken 
to contain only z;, whereas player z’s random tape is replaced by p;R,;. This can be considered as 
applying a simple function A to the transcript r that $ computes. 


Equation 7 holds. 
We wish to show that Equation 7 holds, 


k m Ges) 
VIEW a(a),P(2) Sava) > 
asserting the computational indistinguishability of (Z,a)-parameterized ensembles. What we know 
is that Equation 6 holds, 


§O:(275S) 


VIEWS Ts 


A(a),P(2p7) 


asserting the computational indistinguishability of (Zps,a)-parameterized ensembles. 
The argument closely parallels Claim ?? in the proof of the main theorem of this thesis (page 77). 
Equation 6 means that for any polynomial-size family of circuits {Dz}, 


z k g0(287:f) 
e(k) = max |EDy(VIEW 404) ece¢n) ~ ED (S400) )| 


is negligible. Let 
€és(k) = max |ED, (VIEWS A(a), pes) = ED,(Sq5" DY, 


where p € {0, 10 a and Sis given by Equation 12. Then the weighted sum 


é'(k) = max |2-"* >> ek) 


pe({0,1}*)* 


is negligible. Now we can bound this from above by 


7 ef k 0,(#97;/) 
i 2 a ein [EDs (VIEW 44) ore) ~ EDs (Satay | 
P fr n 


> nax 2-"¢ >> ED,(VIEWS a) psn) 2" ED.(SoGF*D) 
pe({0,1}*)* pe({0,1}4)* 
= €(k), 


using the triangle inequality: }>|.A; — B,| > | D(A: - Bi)| =| Ai— Lo Bil; thus e’(k) is negligible. 
With A the map specified earlier (taking a transcript r with input z,p,3; and random tape A; 
to a transcript with input z; and random tape p,;R,), we conclude that ¢”(k) is negligible, where 


max2-" > ED,(A(VIEW/(a),a¢epn)) 2 EDa(A(Sitay”)) 
pe({0,1}*)* pe({0,1}*)* 


Imax ED,(VIEW (a), P(z)) = EDs(S8))| 


é"(k) = 
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by the definitions of P, P, and ©. This being negligible is precisely what is is needed to establish 
the claim. 


An alternative way to look at 9. 


Reviewing what we have defined, the oracle 2 can be described as follows: it chooses a random 
pad p, selects 3 as we have specified, and then, to a component query of 7 preceding the output 
query, 2 responds 27,9;3;; to an output query of 7,.7,5,, 9 responds with y@(jp U py), where 
y — f(#p U Zp); and to subsequent output queries i, 2 responds with (2;7:p;8;, DiDY:)- 

There is another way to describe the behavior of 2, which is identical. Namely, Q chooses 
random f and p as above, selects & as we have specified, and flips coins to select a — ({0, 1}‘)". 
Then, to a component query of i preceding the output query, 2 responds Z,p;3;; to an output query 
of Fp Prsy, © selects y — f(z, U fy) and responds with wy U pr@yr; and to subsequent output 
queries i, 2 responds with (z; w; 3;, wi@yi). 

The advantage of this description of 2 is that now it is apparent that 2 can be simulated using 
only the aid of an O,(Z; f) oracle; we thus change the arguments to this oracle to 2(Z; f). 


Protocol P is private. 

Consider the simulator $ which is identical to § except that in any transcript 7 that 9 would 
output in which a player had a private output of y and a random string prefixed by p,, S$ outputs 
the same transcript, but with player : having private output of y; given by Equation 5. This can 
be considered as applying a simple function, h, to the transcripts r that $ would output, and 
eas A(r) instead of outputting 7. Applying A to both sides of Equation 7, the definitions of 

P, P, § and S§ gives that 


k ~ @hX2;f) 
VIEW A(a),P(2) * Sa(a) . 


Oracle S is defined to behave like S, except that it simulates the behavior of 2 with the aid of 
an O,(Z; f) oracle; we have already discussed why this is possible. By construction, then, the last 
assertion gives that 


O;,(2;, 
VIEW 4a), P(2) od ona) oe 
as desired. 


Protocol P is correct. 


The committal function ¥4 was a well-defined committal function associated with simulator S$ 
for A attacking P. By our definition of the simulator S, y4 = X4 remains a well-defined committal 
function associated with 5, for A attacking P. We know that, almost certainly (over coin flips F 
and r4, and uniformly, across (Zp$, a)), each good player running P computes fil (ZS, #14, 4, k)). 
Whenever this event occurs, each good player i in the protocol P computes fil X(ZPS, 7, 74,0, k)) Op; = 
fiOxc(Z, BF, ra, @, k)). Almost certainly, then, each good player i computes fj(x(Z, 7, ra,@,k)). 

a 


5.4 Independence of Committed Inputs 


This section demonstrates that what the adversary commits to in an execution of a secure protocol 
is essentially independent of the inputs held by currently uncorrupted players. Stating this theorem 
in a precise yet intuitive way is tricky — both because the adversary necessarily can commit values 
which are quite dependent on the values held by good player (but somehow they are not meaningfully 
correlated), and also because the number of players and the input length are not regarded as being 
fixed. 
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5.4.1 Minimum dependence on input distributions 


Let I = {I,} and I’ = {I!} be families of distributions, each c € U Ly specifying distributions I, 
and J’ on tuples (Z,4,a,,c) € Ly. We wish to investigate the adversary’s limitations in guessing 
which of the two distributions the initial configuration is drawn from. To do this, consider the 
following two games: 


Game 1 [Distinguish / and I’ using a secure protocol]. A protocol P which t-securely 
computes f = {f.} is run in the presence of a slightly “special” polynomial-time adversary A. The 
speciality of the adversary consists of her being able to specify—via a network interaction function 


Guess: {0,1}" > {0,1} 
—_—— —_—=— 
current guess of 
state T or yd 
which gives A’s “guess” as to whether the input configuration was drawn from J or from J’. When 
the adversary’s committal becomes well defined (as specified by AZ) the bit specified by Guess is 
taken to be this guess. 
To quantify how well the adversary A does in distinguishing J from J’ during the execution of 
protocol P, define the adversarial distinguishabdility of these ensembles by 


adv-dista pr(c) = | Eyz,4,04,c)—Ie Guess, p(Z,4,a,a,c, FTA) — 
a, 


E2,4,04,c)—It Guess 4, p(Z, Ga,C, r, Ta) | ’ 


where Guess, p(Z,@,4,4,c, 7,r,4) denotes A’s guess when the initial configuration is specified by 
(z, a, Ga,C, r, Ta). 


Game 2 [Distinguish I and /’ using component queries]. Let D, be a distinguisher having 
access to an ideal evaluation oracle 2(7,a). (That is, the oracle only makes component queries, 
no output queries. There is, implicitly, some bound t on the number of permitted queries.) By 
Dayzay(c, a), where c = 1° #1°#1'#1'#1"#C,, we denote the distribution induced on D’s output 
when its input is (c,a,) and its oracle responds to up to ¢ component queries i with (z;, a;). 

To quantify how well D, distinguishes between I and I’, define the inherent distingutshability 
of these families of distributions by 


inherent-distp, 1,1'(c) = [Betenont DMFEAD(e, aa) = Ey2,4,a4,c)—1, DU? (¢, a,)| . 


The inherent distinguishability of ensembles J and I’ can be considered as a lower-bound on the 
extent to which they can be distinguished by polynomial-time algorithms given the ability to 
adaptively “open” a bounded number of components of (Z, @). 


One expression of independence of what the adversary is committing to lies in the fact that the 
adversary cannot win at Game 1—where she gets to run protocol P—significantly better than she 
could win at Game 2—where she does not bother to run the protocol at all, but just talks to an 
ideal evaluation oracle which can make at most t component queries, instead. More formally, we 
have the following theorem: 


Theorem 5.9 Let P is at-secure protocol for some function family f. Then for any t-adversary A 
there exists a distinguisher D, such that for all pairs of ensembles I = {I.} and I' = {I/}, 


e(k) = sup |adv-dist, p1(c) — inherent-distp ,,1(c)| 
exh y..- 


is negligible. 


68 


Proof sketch: Since P is a secure protocol for f, there exists a simulator § which, when given 
an {,(Z,d)-oracle and interacting with an adversary A having advice a, and sharing common 
input c with the network, provides to A a view computationally indistinguishable from that which 
the network provides on input (Z,d,a,,c). The distinguisher D, existentially guaranteed by the 
theorem is constructed from S by simulating S interacting with A—but halting this simulation at 
the point at which S attempts to make its output query. The output query is not made; instead, 
at this point D reads off A’s guess Guess, outputs the bit which it specifies, and terminates. Note 
that the simulation—since it never actually made its output query—can be carried out with only 
an 2,(Z, @) oracle. 

To see that this algorithm D achieves the bound of Theorem 5.9, note that, by Proposition 5.4, 
the ensemble provided by S$ to A when the initial configuration is I-distributed is computationally 
indistinguishable over J to that provided to A by the network when the initial configuration is 
I-distributed. Similarly, the ensemble provided to A by S is computationally indistinguishable 
over I’ to that provided by the network when the initial configuration is J'-distributed. The result 
follows by Lemma 5.5 and the transitivity of indistinguishability (Proposition 5.2). a 


REMARK. Add in: The same theorem with f value given to both. 


5.4.2 Minimum dependence on good inputs 


Let I = {I,} be a family of distributions, each J, a distribution on tuples (Z,d,a,4,c). Let B be any 
predicate on vectors, B : U,>3¢>0({0, 1}‘)" + {0,1}. (Predicate B need not even be computable, 
even for the case computationally bounded case of this theorem.) Consider the following two games: 


Game 1’ [Guess 8 using a secure protocol]. A protocol P which securely computes f = {f.} 
is run in the presence of a polynomial-time t-adversary A. The adversary is again equipped with a 
network interaction function to allow it to specify a “guess” Guess. This time, Guess is interpreted 
as specifying a a “guess” by A as to the value B(Z), a guess which is specified when the committal 
is made by A. The input configuration is distributed according to /,. 

To quantify how well the adversary does in guessing the predicate B, define the adversarial 
approzimability of B by A over I as 


adv-approz, pg 1(c) = Prob(Guess, p(Z,4,a,c, 7,74) = B(Z)], 


where the probability is taken over (Z,d,a,,c) being distributed according to J, (where c = 1* ---), 
and the uniform distribution on coins r and r4. Here Guess,4,p(Z,d,a,c, 7,74) denotes the guess 
that A makes (as specified by Guess) in the execution of protocol P when the initial configuration 
is given by (Z,d,a,c, F,r,4). 


Game 2’ [Guess B using component queries]. Let G be a distinguisher having access to an 
ideal evaluation oracle 2(#, a). By G*)(c,a,), where c = 1'#1"#1'#1' #1" #C., we denote the 
distribution induced on G’s output its input is (c,a,4) and its oracle responds to up to t component 
queries 7 with (2;,a;). 

It is G’s job to guess the value of B(Z). To quantify how well D does this, define the inherent 
approzimability of predicate B by 


inherent-approzg p ;(¢) = Prob[G**)(e,a,) = B(z)], 


where the probability is taken over (Z,d,a,,c) being [,-distributed. The inherent approximability 
of predicate B over I can be considered as a lower bound on how accurately B(Z) can be guessed 


69 


by a polynomial-time algorithm when the initial configuration is [-distributed and the algorithms 
are given the ability to adaptively “open” a bounded number of components of (7, 4). 


One expression of independence of what the adversary is committing to lies in the fact that the ad- 
versary cannot win at Game 1’—where she guesses B based on arun of the protocol P—significantly 
better than she could win at Game 2'—where she guesses B by just talking to a ¢-bounded oracle. 
More formally, we have the following theorem: 


Theorem 5.10 Let P be a t-secure protocol for a function family f. Then for all polynomial- 
time t-adversaries A there exists a polynomial-time distinguisher G such that for all families of 
distributions I = {I.} and for all predicates B, 


e(k) = sup |adv-approz, p.»,1(¢) ~ inherent-approzg,»,,(¢)| 
c=l*... 
is negligible. 


Proof sketch: The proof is similar to that of Theorem 5.9. As before, fixing an adversary A and 
letting S be the simulator establishing security, the guessing algorithm G is constructed from S$ 
by running the simulation of S interacting with A, but halting this simulation at the point at 
which S attempts to make its output query. The output query is not made; instead, G reads 
A’s guess, outputs this bit, and terminates. That the distinguisher G approximates B nearly as 
well as the adversary approximates B when attacking the network running P and when the initial 
configuration is [-distributed follows along the same lines as Theorem 5.9. a 


5.5 Reducibility 


Suppose you want to design a secure protocol for some complicated task—computing some func- 
tion f, say. In an effort to make more manageable your job as protocol designer, you assume in 
designing this protocol that you have some primitive, g, at your disposal. (As an example, you 
might wish to design protocols assuming the ability to perform an oblivious transfer between any 
pair of players.) You prove that P% securely computes f with respect to a “special” model of 
computation, one for which an ideal evaluation of the primitive g is provided. 

Now suppose you have continued your work and designed a protocol P, which securely com- 
putes g. It is secure in the “generic” model of computation. 

One would hope that you obtain a secure protocol for f (in the “generic” model of computation) 
by inserting the code P, wherever it is necessary in P% that g be computed. Such a reducibility 
property offers the promise that we can not only design protocols top-down, but that, associated 
to this design scheme, is a modular proof of security. On the other hand, without reducibility, 
modular design of secure protocols may be impossible. 

In this section, we show that our notion of security allows reducibility, establishing, after the 
necessary preliminaries, a powerful reducibility theorem in Section 5.5.5 


Before launching into effort, we wish to emphasize that reducibility is not the same as compos- 
ability. In fact, reducibility is more subtle and interesting than serial or parallel composition. These 
properties capture the sense in which, say, the concatenation of secure protocols remains a secure 
protocol, or the parallel execution of secure protocols remains a secure protocols; but reducibility 
captures the sense in which an ideal protocol can be replaced by a secure protocol. An explanation 
of this notion necessarily requires the construction of specific computational models and notions of 
security. 
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Figure 4: Left: a protocol and an adversary, sharing the ability to do ideal g-evaluation. The 
traffic is defined to include the information coming into and going out of the adversary-side of the 
box labeled g. Right: the simulator providing all traffic to A — including the appearance of the 
box labelled g. 


Some of this section is rather formal. We comment that we have found it impossible to reason 
properly about reducibility when “intuitively clear” concepts like how to compose protocols are not 
formalized; thus, we must specify an extremely ezplicit model of computation—and one tailored to 
making it relatively facile to state and prove our theorems. 


5.5.1 Issues in reducibility 


Reducibility brings to light a variety of issues, including the need for devising special-purpose 
models of computation and their corresponding notions of security, the importance of input and 
output awareness, and the need for auxiliary inputs and adversary advice. We briefly discuss these 
issues in this subsection. 


SPECIAL-PURPOSE MODELS. When a protocol is designed under the assumption at we provide a 
certain primitive “for free,” there must be formal notions crafted to reflect the new scenario. 

The abstraction this special-purpose model is meant to capture can be described as follows. 
The players are given a physical “box” to use to collaboratively compute g. At the beginning each 
round, good and bad players insert values along the input wires to this box. At the beginning of 
the nezt round, good and bad player get the appropriate output back along the output wires of this 
box. The box, of course, faithfully computes the function g applied to the vector of values coming 
in along its input wires. 

We need to make this abstraction into a definition of a protocol in the model of computation 
allowing ideal evaluation of g. For simplicity, we imagine that the protocol makes just one call 
to the ideal evaluation of g, for the case where this occurs more often (or even every round) is 
then easily handled. Explicitly, at the end of some particular player round 7, each player is to 
have “written” in his computational state his input w, to the ideal evaluation of g. Likewise, the 
adversary, at the end of her round 7, must have “written” in her computational state some tagged 
vector wi, where T is the set of currently-corrupted players. At the beginning of the player’s next 
round, each good player i learns the g;(w7U w’), while, at the beginning of the adversary’s next 
round, she is given g7(wyUw). This model of computation is pictorially depicted on the left hand 
side of Figure 5, and it will be formalized in Section 5.5.3. 

After understanding the revised model, we must describe what security means for it. The 
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notion is essentially the same as before: in particular, one demands a simulator that produces the 
appropriate views for the adversary. Of course, these views now include the output from the ideal 
evaluation of g. But the simulator is given no special abilities to produce these outputs. The notion 
of player and adversary traffic, though, is slightly amended to accommodate the new scenario, as 
we now discuss. 


AWARENESS. Note that if the players have a physical “box” to use to collaboratively compute g, 
then the values wy that the adversary inserts along the “input wires” to this box should thus be 
considered as part of her traffic—something the adversary is definitely is aware of. Similarly, the 
values gr(wy U wy) that the adversary gets back along the “output wires” of the box are again 
something she definitely knows, and should be considered as part of her traffic. 

The construction of the simulator implicit in the claim that we have a secure protocol in the 
model of computation providing an ideal evaluation for g will, in general, need to have the simulator 
“see” the adversary’s contribution w7: if the simulator were denied this information, it could not, 
in general carry out the simulation—as can be seen by considering the case where g is the identity 
function, g;(w) = w,. 

Furthermore, modeling the idea that the adversary can extract the output received from the box 
is important. Imagine the “box” being replaced by a protocol, and suppose an adversary derived 
from A’—an adversary designed to attack the protocol with ideal g-evaluation—is to be set loose on 
the composite protocol. Even if the adversary promises to make no corruptions during the execution 
of the subprotocol, there is still no natural sense in which the adversary attacking the composite 
protocol can be derived from an adversary attacking the protocol with ideal g-evaluation—unless 
we mimic the possession of adversary output in the ideal evaluation of g. This would show up 
as a technical impediment to establishing reducibility, prohibiting the natural construction of a 
simulator. 


AUXILIARY INPUTS AND ADVERSARY ADVICE. At the time at which an abstract protocol for g is 
invoked, the players are in some computational state. Most of this computational state is irrelevant 
to the computation of g. However, it might be highly correlated with other player’s inputs to g. 
Were we not to have included auxiliary inputs in our formulation of security we would be unable to 
assume that the adversary, being granted this information associated to player 1 when she corrupts 
him, would admit simulatability. Similar statements apply to the adversary’s advice. 


5.5.2 Subroutine composition 


For protocols designed for subroutine composition, we augment the notion of a protocol as follows: 
in addition to the four interaction functions associated with a protocol—n, M, m and o—we provide 
a subroutine input function 
t: {0,1}° > {0,1} 
——— —— 


current input to 
state subroutine 


To describe our reducibility theorem, it is necessary to specify the mechanics by which one 
protocol calls another. For simplicity, we will describe only the case in which a protocol P calls an 
R-round protocol Q, and it does this at some particular round 7. 

The sequence of computational states that a player goes through is depicted in Figure 5. We 
establish the convention that there is no activity in the players’ rounds 0, 7+ 1, and 7+ A+ 2, and, 
consequently, there is no message delivery to the players in rounds 0, 1, 7+1, 7+2, #7+R+2, 7+R+3. 
Notice how saved state from the subroutine call is not considered part of the computational state 
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Player round Adversary round 


0 (32°, oie a; ) * 
0 
1 (37°, r?°, a;) 
1 
ra (sf, rf, ai) 
T 
r+i1 (o( sf Hi, ue a; 4s; ) * 
F+1 
si (sft, rf, att) 
F+2 
_ 1 R 1 1 (arr arie pf tR+1)0 a;{37) 
T i ee} » “tag 
T+R+1 
r+ R42 (sf so(sftF+1), pf+R+! g.) :. 
F+R+2 
FE R43 (sf+0(sftF+1), rf+R+1, g,) 
T+R+3 


Figure 5: The sequence of configurations at the beginning of player i macro-rounds in a protocol 
that calls an R-round protocol at time 7. 


of a player; this ensures that a protocol only depends on what it “should” depend on. Formally, 
the sequence of player configurations is defined as follows: 


(P(e, s;°), 77", a") if N(s;’) = compute and either 1<r<forr>r+R+3 
(Q(c, 35°), rf", a;”) if N(s{’) = compute and r € [F + 2.7 + R+ 1) 

Ce 
(sf? srif, rigrig ++, ay’) if (sf?) = flip-coin and r ¢ {0,7 + 1,7 + R+ 2} 


C7? otherwise 
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(sf+Mi, rf, af) if N(s7) = round-done and 
r€é{0,7,7+1,7+R+1,7+R+2} 


certo 8 (o(sf ti, rf, aftsf) ifr=r 
(sfeo(st), rf, af) ifr=7r+R4+1 


CT otherwise 
while the adversary’s sequence of configurations is given by: 
(A(e, 37), 777, af, KY) if N(s"?) = compute 


rp. orp rp orp rp rp ‘fe AS( OTP . £1 ‘ 
(ser, Mr: +, af, KP) if N(8"2) = flip-coin 


on (sfea'e,, 77’, aat,---, KP) if N(s%?) = get-advice 
(sof, ry, ay, Kg U {t}) if N(s"?) = corrupt, 
CZ otherwise 

Clrtio (samt, r,, 04,84) ifr ¢{0,7,F+1,7+R4+1,7+ R+2} 

: (34%, 74, Oa, Ka) otherwise 
where 
BE tes ie ifr é€ {0,1,7+1,7+2,7+R+1,F7+R+2} 
i Si *z,#a;4M),*---#M" *E(H]) otherwise 


and all other notation is as before. The player and adversary traffic have the same formal definition 
as given previously, except that we add the proviso that all messages (M7, mj,, etc.) are defined to 
be the empty string, for rounds 0,7 +1, andr+R+2. 


REMARK. Notice that if the adversary corrupts a player i during the execution of a subprotocol, 
the adversary necessarily “learns” player i’s input 2; = (37) into the subprotocol, since the saved 
state sf was preserved and given to the adversary on corrupting i. The same preservation of player 
input values was built into the definition of executing protocols in the presence of an adversary—in 
the handing to the adversary on the corruption of player i the initial private input 2; belonging to 
that player. 


5.5.3. Protocols with an ideal evaluation 


Let g = {ge : ({0,1}‘)” + ({0, 1}')". We consider an enriched model of computation in which the 
players can compute the function g “for free.” 

To define the running in the presence of an adversary a protocol P? which assumes the ideal eval- 
uation of a function g, we augment the notion of a protocol as we did for subroutine compositions, 
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Player round Adversary round 


T (sf, ae a; ) 


- 

- 
r+1 (-(s;)ti, 77, aitst) * 

r+i1 
7T+2 (sf *gi(t1,°-+, tn), ee a; ) x 

stl egr (ti, +++ ln) 742 

r+3 (sf #gi(t1,---, tn), rs a;) * 

r+3 
r+4 (sf #gi(t1,°++, tn), ae a;) 

r+4 


Figure 6: The sequence of configurations at the beginning of each macro-round for a player i in a 
protocol in the model of computation providing ideal g-evaluation executed at round 7. 


by adding a function « on player computational states, 


t: {0,1}" > {0,1} 
——_ —=—— 


current input 
state tog 


Similarly, we augment the notion of an adversary by adding to the four interaction functions 
associated to an adversary a g-input function 


ts {0,1}° — glt-nb (ou? 
current input 
state tog 
The behavior of a protocol with a ideal g-evaluation is depicted in Figure 6. We establish the 
convention that there is no activity in rounds 0,7 +1, 7+2, or +3, and, consequently, no message 
delivery in rounds 0, 1, 7 +1, # +2, or 7 +3, and # +4. The sequence of player and adversary 
configurations is formally defined as follows: 


(P(e, 77), rf", a5") if N(s;’) = compute and r ¢ {0,7 + 1,7 + 2,7 + 3} 
Chet = (8? ri?, rigrig ++, af’) if M(s{’) = flip-coin and r ¢ {0,7 + 1,7 + 2,7 + 3} 
Gi otherwise 
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Mi ie) if r ¢ {0,77 +2} 
Clrtiyo (o(s;)fi, rf, af hsf) ifr=F 
i (s7#g;(t1,-++,¢n), Tf, af) ifr=F+] 
Ci otherwise 


while the sequence of configurations the adversary goes through is given by 


(A(c, 87), 777, a, wie if N'(s"?) = compute 
(sar, Tari: ++, a, KL) if N(s%) = flip-coin 
ce = (spay, 77, Oyo@as **') Ka) if N(s77) = get-advice 
(sfeol, rf, af, KP U{i}) if M(s7?) = corrupt, 
Cy otherwise 
(34M, 7%, a, Ky) if r ¢ {0,7..7 + 2} 
r+1)0 . = 
cs ) (sy*9r(tiss**stn)s M4, Oa, Ka) r=F+1 
(Sky Tan Gay Ra) otherwise 
where 
: ust)  ifig «ft 
; i(sit') if te wit? 
. . 1 
i = {(u): te RY} 
and 
SF #2 5*0; ifr € {0,1,7+1,7+3,7+ 4} 
oe = SF #2, #0;*9;(t1, °°, ln) ifr=F7F+2 


Si *z,4a,4m},*---#m! +E (HS) otherwise 


Player 7’s round-r traffic is given by 


f= (MJ *Mj*---*#Mrem{,am),*---#m),, Mi+mige s+ «mi, ifrArt+l 
‘ (Mi+Mis---«Mlem',«m,*---#ml,, miemige---#m),, 4) ifr=7+1 
while the adversary’s round-r traffic is given by 
(Mx, (ins 0%,)s ++ +5 (ims OF)» AAA) ifr ¢ {F + 1,7 +2} 
i = (M4, (415.07, )5- + +9 (tm o7,), M4, tr) ifr=F+1 


(M4, (41,07,), se a lfnis of), M\, gr(t1, wry tn)) ifr=7+2 
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All messages, above, are defined to be the empty string for round r € {0,#+1,7+2,7 +3}. The 
traffic through round-r is defined exactly as before. 


REMARK. Notice how, in the formalization above, the traffic includes the values “input” by the 
adversary into the ideal evaluation of g, and the values “output” by this ideal evaluation are, in 
the following round, given back to the adversary. 


5.5.4 Security in this model 


The definition of security in the new model of computation is almost exactly what is inherited by 
using the new definition of how players and adversaries interact: A protocol P t-securely computes a 
function f in the model of computation providing ideal g-evaluation if there exists a simulator S for 
it, a t-admissible adversary input function AT, and an adversary output function AQ, such that.... 
Note that the simulator is now responsible for providing the “simulated g-output,” “g7(t1,...,ln).” 
Refer again to Figure 4 for a suggestive picture. 

We said almost exactly because we add on a minor technical detail: we forbid the f-function 
query to be made during the execution of the ideal g-evaluation. More precisely, if AZ(c,T%) = 
not-yet, then AZ(c, 7+?) # not-yet, too. 

This assumption can be justified in several ways. First, allowing an f-output query to be made 
by the simulator during the execution of the ideal g-evaluation goes against the intuition that we 
have properly reduced the computation of f to that of g. Second, we have chosen a formalization 
that allows no message delivery during the execution of the ideal g-evaluation—and it goes against 
the intuition (and the existence of the local input function) to say that a committal occurs at 
a moment when no messages are delivered. Finally, the assumption is necessary to prove our 
reducibility theorem. 


5.5.5 The reducibility theorem 


Under the assumption that g has a secure protocol, and when there is a protocol P% that securely 
computes a function f in the model of computation which assumes ideal evaluation for g, we show 
that we can do without the enriched model of computation: by substituting into P% the code for 
the protocol P, that securely computes g, we get a secure protocol that securely computes f in the 
“generic” model of computation. Diagrammatically, we wish to do without the box labeled g that 
appear in Figure 4. 

If P9 is a protocol in the model of computation that assumes the ideal evaluation of g at round 7, 
and if P, is fixed-round protocol, then by P?s we denote the protocol that consists of P’ modified 
so as to call P, in round #; this is a protocol in the “standard” model of computation. 


Theorem 5.11 Let t € N, and let f: ({0,1}‘)" — ({0,1}')" be a function. Suppose there is a 
protocol P% that t-securely computes f in the model of computation in which it can perform an 
ideal g-evaluation at some fixed round 7. Suppose also that there is an R-round protocol P, that 
t-securely computes g. Then the protocol P = P?*, in which P# calls P, as a subroutine at round 7, 
is a t-secure protocol for computing f. 


Stronger statements of this theorem are possible, but this one was already difficult enough to state! 


Proof sketch: This proof is an unfinished remnant from times past. It requires substantial updating, 
and is left here only to give some idea of the argument involved in the construction of the simulator. 
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Protocol P is the composite protocol consisting of P9 calling P, at round 7, where P% is the 
protocol that computes f in the model of computation assuming g-hardware active at round 7, and 
P, is the R-round protocol computing g. 

To show that P t-securely computes f, we must construct a simulator § = (S,AZ,AQ) and 
show that the simulator “works” to establish privacy and correctness. Before beginning this, fix 
the following notation: that 9% = (S%, AT’, AO’) is the simulator existentially guaranteed for P? 
by its security, and S, = (S,,AZ,,AO,) is the simulator existentially guaranteed for P, by its 
security. We now specify, in turn, the functions AT, AO, and S. 


DEFINITION OF AZ. The adversary input function for P is derived from the adversary input 
function AZ‘ in a natural manner. Given traffic 74, if the traffic is so short that P, has not 
yet been called, we apply AZ‘ directly to 74; if 74 indicates that P, is currently running, we 
return not-yet for AZ(r4), an action which will be justified by our assumption that a simulator 
for a protocol with g-hardware does not makes its f-output query during the simulation of the 
computation of g; and, finally, if r{ indicates that P, has already been completed, then we extract 
the portion of r{ in which P, was running, obtain values for AZ, and AQ, from this portion of 
the traffic, and, using these, construct a recoded version of r4, to which AZ® is applied in order to 
compute AZ. 
Making this more precise, for r > 7 + R + 2, write 


Th = ceK yr (0..7] 
ralF+ 17+ R+1] 
ral? + R+2..] 


where 74(0..7] ends with the (7+ 1) “m”-character in 74; and 74[7 + 1..7+ R+ 1] begins with the 
character following that and ends with the (fF + R + 2)"¢ “a”-symbol in 7%; and r4[F + R + 2..] 
begins with the character following that and includes all of the rest of the string 74. Let 


T, =cen,eTal? + 1.F+ R41] 


where 
Ki, = K,U {i: ete is a substring of r4[0..7]}; 


that is, x’, is the set of all processors that the traffic r{ indicates were corrupted by time (7, ), and 
T, is the properly recoded traffic from the portion of the protocol in which P, was being run. 

Let up be the non-void value up = ATZ,(c,7,[0..r']) associated to some prefix of r,, where 1,(0..r'] 
is the prefix of r, terminated by the (r’ + 1)** “a”-symbol. This is the “input” in the subprotocol, 
as extracted from the traffic. Let yz = AO,(c,1,); this is the “output” of the corrupted processors 
which the adversary could compute on their behalf. 

Let {i,,...,%,} = T be the sequence of processors, in order, corrupted by the adversary before 
the adversary’s committal ur = AT,(c,7,[0..r']) became defined, and let {i.41,--+,i9} = T —T be 
the ordered sequence of processors corrupted after the adversary’s committal up became defined. 
Let sj,, aj, and s;, be defined by the presence of the substring 


eijers;) + 57 farts: 
a 
in T,. The “recoded traffic,” recode(7{), is given by 
recoder’,) = c#K,4+*77,[0..7] 
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eh oat 
02,05; +0; *2;, 


R r 
ei,es; a; #2;, 
lye 


*7T 


014108, 


ca 
Sa41 her a *Zi nat *Viagi 


ee ae 
01,08; , *a;, *Zi, *7i,8 


ral? t+ R+ 2..] 
and, finally, define 


AT4(74) ifr<F 
AT(r4,) = 4 not-yet ifr é [F+1.7+ R41] 
AT (recode(r,)) ifr >7r+R+2 


DEFINITION OF AQ. In an r-round execution of an adversary with protocol P, the adversary 
output is defined by 
AO(r4,) = AO*(recode(r),)). 


DEFINITION OF S. The simulator S for P is produced by “properly combining” the simulators S4 
and S,. The main difficulty lies in properly dealing with the queries made by the simulator 5,, 
since § lacks the O(’, #*3; g)-oracle which S, expects. 

Simulator $ will “simulate” the simulators $% and S,. To this end, it uses separate and inde- 
pendent coin flips rs, and rs,. The simulator S is defined as follows: 


1. Rounds 0..7. Beginning with the simulator’s round 0 and continuing until the simulators 
round 7, S behaves exactly as S% behaves. That is, S simulates the behavior of 5% during 
these rounds, communicating with A exactly as $§ would communicate with A. At the end 
of this, the simulator S% is in some computational state s§,, with some set of corrupted 
processors at this point Ki. 


2. Rounds #+1..7+ +1. Beginning with the simulator’s round 7+1 and continuing until the 
completion of the simulator’s round # + R +1, simulator § runs the simulators S# and S, in 
the manner we now describe. 


Simulator $ continues to interact with A, but now it uses the algorithm S, to decide on its 
messages to A. Simulator S, is initially in computational state cxx’,. There is an immediate 
question that must be answered: how is the simulator S$ to answer S,’s oracle queries when 
it is not equipped with an (i, @{3; g)-oracle. We now describe how S does this: 


(a) When A corrupts a processor i and, consequently, S, makes a component query of i, 
processor i has been corrupted, and so S “knows” a string sf *a,;{3{+z;. The algorithm 
S simulates S* having just received a corruption of i and component query answered by 
(c(sf), a;tsf). The simulator S, outputs a string for A which S itself outputs for A. 
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(b) Similarly, 54 is told that processor 7 has just been corrupted, and $9 is given a component 
query response of (z;,4;). Simulator S% prepares an outgoing message for the adversary 
with which it interacts, but this message is ignored by S. 


(c) Suppose now that S$, make an output query of 1. Then :;m is properly appended to the 
traffic r# between the simulator S? and the adversary (indicating the end of round r+1, 
as far as S! is concerned), and 59 is allowed to run, determining a value yr = 5 (sft 19), 
The output query of 5, is now answered by yr. 


(d) If, in the future, a processor 7 is corrupted, then S just learned a value s{a;#s**z;. Simu- 
lator S# is then executed with component query i answered by (2;,a;). The simulator 99 
returns a value s/*a,{s{*7;. The component query of 5, is answered by ((¢(s/), ats[), 7;). 

(e) When round *+ R +1 has been completed, the traffic r for the simulator S9 is updated 
by appending a “m”-character, indicating—to $’—the end of round 7 + 2. Simulator $9 
is now in some computational state s%*?. 


3. Rounds [7 + R+2..end]. During A’s round 7 + R + 2 and continuing until termination, $ 
behaves exactly as $9 dictates, beginning in state s%*?. 


THE CONSTRUCTION WORKS. To argue correctness, we begin by constructing an adversary A’— 
intended for attacking protocol P’—and an adversary A,—intended for attacking the protocol P,. 
Of course these adversaries are constructed based on adversary A. 


DEFINITION OF A,. Adversary A, is precisely adversary A, except that its advice is used to 
initialize its state. That is, the first thing A, does is request some advice, the answer to which 
determines the initial state of A,. Thereafter, A, behaves exactly like A. The security of P, 


DEFINITION OF A¥. The adversary A’ behaves as follows: 


1. Rounds 0..7. Between A*’s round 0 and A%’s round 7, inclusive, A’ behaves exactly as A 
behaves. That is, A’ simulates the behavior of A during these rounds, corrupting processors 
when A does, and communicating with the network with which it is running exactly as A 
would. At the end of this, the simulated adversary A is in some computational state 34. 


2. Round #+1. During A’’s round # + 1, A® will “play a game in her head”—a game which 
we now describe. During this game, various processors will be corrupted, and the state of 
adversary A will be updated. 


In this game, the adversary A’ simulates the behavior of A—beginning in state 54+ talking 
to the simulator S,. The coins A% uses in the simulation of S, are distinct and uncorrelated 
to the coins A’ provides to the simulated adversary A. There is an immediate question that 
must be answered: how is adversary A’ to answer the simulator S,’s oracle queries when, in 
fact, A% has no oracle? We now describe how A* does this. 


(a) When, in the simulation, A corrupts a processor i and, consequently, S, makes a compo- 
nent query of i, A’ actually does corrupt processor i. This results in A’ obtaining a string 
c+i( sf )#i+a;+s;. The component query asked by 5S, is then answered by (c#c(sf)#i, a;+sf). 

(b) When S, makes an output query of vp, A’ encodes within its computational state the 
formation required so that i(s4,,) = ur and N(s%,.) = round-done. At this point in 
time, with the simulated adversary A in some computational state s oe AS is done with 
its round 7 + 1 activities. 
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3. Round #+2. At the beginning A%’s round 7 + 2, she has been presented a set of values 
yr. (If Af is interacting with a network, yr = gr(t,-*-tn)), where T is the set of currently 
corrupted processors and 2; is given by Equation ??.) Adversary AY uses yz to answer the 
oracle’s output query, and the “mental game” A? is playing using A (which is now in state 
s",") continues. This may result in additional corruptions by the simulated adversary A. 
When the simulated adversary A corrupts a processor 7, resulting in S$, making a component 
query of i, A¥ actually does corrupt processor i, obtaining a value s?+7,+a;. The component 
query is then answered by ((c#z(s/)+#1, a;*s7), 7;), and the simulation continues until A’s 
round # + R+1 has been completed. After that, with the simulated adversary A’s in some 
computational state s%,*"*+!, adversary A is done with her round 7 +2, and enters round-done 
into her computational state. 


4. Rounds f+ 3..end. During A%’s round F+3 and continuing until its termination, A’ continues 


to simulate the behavior of A (starting off in state s%,*"+!+—until A terminates. At this point, 


A’ terminates as well, outputting what A outputs. 


5.6 Existence and Other Folklore 


5.7 Discussion 
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